Skills Clinics

About this Episode

We talk about something specific here at Acima with the hope that other companies will replicate our skills clinics because it's been an extremely valuable thing that we've done.

Transcript:

MIKE: Hello and welcome to another episode of The Acima Development Podcast. I'm Mike Challis. I'm hosting today. We've got a group here that I think has been here before, so I won't start with introductions. But I'll say names as people speak so that listeners can know who they're listening to.

Today we have a topic that I'm excited about. I'm generally excited about the topics, but today is one that's kind of close to my heart, and it's what we call our Skills Clinic. Usually, we try to keep things general. Today we're going to be talking about something specifically that we do at Acima that I hope other companies will replicate this idea because I think it's been an extremely valuable thing that we've done.

Let me give some history. About, I don't know, a year and a half ago, the beginning of the summer of 2021, we hosted an internship. And one thing that we've noticed...and this applies to the internship but it also applies to a lot of other situations in which new developers come into software development. Now, there are people who come through a very traditional path into software. They go to a four-year university. They get a degree in computer science or something similar. They do an internship somewhere, and they go, and they get a job.

But there are a lot of people who don't follow that path to get into software development. And there are a lot of programs out there to try to bridge that gap. One thing that exists is software bootcamps; a lot of people have used those, which tries to very quickly get you knowledgeable in software. This applies to people who've maybe got a degree somewhere else, or have work experience or, you know, years living adulting. [laughs] So they have a good sense of how to do things in life and maybe have experience in computing but haven't learned the tools of software.

So they'll go, and they'll do a really intense bootcamp for two or four months, something like that, and then move on to getting a job, you know, an expedited path. That's a great way to get into software if it works for you. Certainly, there are going to be some things left out compared to what you get with traditional computer science.

A lot of people complain about computer science programs that they teach a lot of theory and not much practical experience. People can come out of a computer science degree and really have no idea [laughs] how to work in a real-world setting and have to learn those skills. So there are some advantages to both sides. But there are some gaps if you've gone to bootcamp so basic theory things you don't know that can sometimes hold you back.

One thing that we've done a lot is provide mentorship and internships so people internally who have not worked in software can kind of learn the ropes and move into coding and build their skills as they go. I think it's a great way to learn. A lot of people out there in the industry learn that way. And I strongly encourage it if that's something that interests you. But once again, there's often this feeling that like, oh, there are these things I didn't learn. There's not a bootcamp for people who are already working. It's something that gets you up and running but doesn't follow up after there.

People who come from a traditional computer science background as well maybe they want to learn things outside of what they learned in school or outside of what they're doing at work and build their skills. All of these people have this need to have ongoing development, ongoing learning. Oftentimes, the work environment doesn't necessarily provide that. It gives you hands-on experience but not necessarily the theory, you know, things that would build those fundamental skills. A lot of background here; I'll give one more piece of background.

When we were looking to do this internship, there was a product manager who worked with us who mentioned that his daughter was really an avid volleyball player. And during the summer, she really wanted to build her skills, and there were lots of programs around. I don't know about lots, but several programs around that will provide that opportunity, and what they call themselves is a skills clinic.

A skills clinic is not for people who've never played volleyball before. And this exists in other sports as well. It's not for somebody who's never played before. It's for somebody who knows what they're doing but wants to do drills, wants to build their fundamentals so that when they go back and play the real game, they're better at it. We said, "Well, that is the perfect name. That's the perfect name."

We need to have something like that. We need to have a skills clinic for software so that we have an opportunity to build our fundamentals to do that practice outside of our normal routine that builds the fundamental skills so that when we go back to our work, we are stronger, better, more confident, and can be better coders. So we started a program where an hour or so each day for the internship and for anybody interested...there have been a lot of junior developers, but there have also been more senior developers who've joined to get together and work on some fundamental skill, and we've called that skills clinic.

We did it during that internship and just kept it going. So for about a year and a half, we've been doing more or less daily, I'd say more, [laughs] almost always daily, a skills clinic where we get together and work on something. We started with some almost lecture-like formats where we did a presentation, talked about a computer science concept, and we've actually, by design, moved away from that. Asked for feedback and found that, yeah, that's great, but it's really hard to engage with a presentation like that.

And over time, we've moved more and more toward hands-on experience. So we're writing code, but we're writing code outside of what we'd normally do at work in a way that would teach us something new. So we have learned some basic computer science concepts and learned about how computers work, [laughs] the basics of a processor. Then I think we learned a lot more by writing some machine code [laughs] to learn how that works, not very much because that's a pain.

But then we wrote some Assembly. We looked up the specs for, you know, x86 computer and figured out the Assembly language to do a basic addition operation and then moved on. We wrote some other low-level languages. And then, we thought of low-level code in a low-level language. And then we took some time writing our own languages. We split up into several groups, and we wrote our own programming languages. I thought that was a lot of fun.

We've gone beyond that point to work on a number of different projects. And it's a great opportunity for people to get in and build their skills. It's important to me because I helped launched it, but honestly, I have not been as involved with it for a while. My role has changed somewhat. But we do have Tad on the call with us, who has really pushed it forward, as well as Ramses, who's helped a lot with that.

And they have kept this going, and they've been a great asset, I think, to the other developers and to the company. I'm curious to hear what Tad and Ramses...what do you think? I've kind of talked about how we launched it. I'm curious what you've been doing for the last several months as well as your thoughts about the value of skills clinic.

TAD: Well, what we've been working on primarily is a chatbot for our company's Slack channel. The interesting thing is that we kind of just do whatever people need to be done. We have a default project that we work on every day. But there have been a few times we just barely finished our internship program for the summer, but I've just talked to the interns and been like, "Hey, what do you need? Like, what holes do you have? What are you missing?"

And some of the days we just talk to the interns and let's say like I don't get this CSS thing, or I don't get this JavaScript thing, or I don't get this, whatever. And it's just kind of an open forum for people to come in and say, "I'm curious about this," or "I feel like I have this kind of hole in my knowledge," or things like that. And we'll fill those in. But it's been really nice to just have a default project that we work on every day.

The project that I mentioned, the chatbot, has been really interesting. I chose the project because I wanted to do something that had a really good feedback loop, meaning you can write some code and get an immediate response and some satisfaction from what you're doing. And chatbots are kind of like that where you can write...in our chatbot framework, they're called handlers where they just handle...you say if you see this certain string or if you match this regular expression, then do something with it. And so to be able to, in 10 minutes, write a handler that can return a dad joke when you ask for a dad joke, or something like that has been really interesting.

We do primarily Rails development. And so I chose a project that wasn't Rails just because Rails does a lot of things for you and has a lot of opinions. And so I wanted to choose a project that we could kind of build-up from scratch and make decisions as we went and get into the nuts and bolts of things without that kind of Rails [laughs] paradigms and Rails convention and everything kind of hanging over us. So it's been really interesting. We've encountered tons of little things that I don't think you would encounter working on a Rails project but are very common problems that developers have to wrestle with, just generally speaking. So it's just been really interesting.

MIKE: I think you said a couple of things that I noticed when working on this that are important for keeping a program like this going in the long term. You said you have a long-term project that provides opportunities for learning.

TAD: Yeah.

MIKE: I found that getting things started as well to be exceptionally valuable. At first, I was preparing a presentation every day, which was fine. And I guess you could do that if you had time. But that wasn't as engaging. [laughs] When people had an interesting project to come back to, it kept that continuity. And it's not that we would do that every day, but that continuity was really helpful to allow people to continue. And if you have an off day where you didn't have time to prepare, well, that's great; people can pick up where they left off.

TAD: Yeah, I started out the same as you when I was doing the skills clinic, where I was constantly trying to figure out material to present. And it was taking a lot of research, and I was going back through old college notes and stuff. And like, oh man, what are all the things that I could teach these folks? You touched on it where it's like, okay when you come through a bootcamp, you get a lot of experience, but it's very narrow and how do you broaden that out?

And so it's like, okay, well, what are all these topics that I can do to broaden out their understanding into all these things? And it turns out that just working on a project that is not the same as what you're doing in your regular day-to-day work was just, well, I don't know if it's serendipity. It's just surprising how many common developer problems and patterns came out of just working on a project together.

And I didn't have to sit and research all these things. It's just like, oh, yeah, we've hit a snag, or we've hit an issue. How do we solve it? Oh, you know, there are already patterns or solutions out there. Let's talk about it and figure out which one works for us. And that has been really surprising to me almost.

MIKE: I've had a similar experience that you actually get your hands on the keyboard...this applies beyond software, you know, we talked about this skills clinic. When you go out into the real world and do real things rather than just talking about them, it's remarkable how much you notice that you don't notice when you're just trying to explain to somebody.

You notice this a lot when onboarding somebody who's just started somewhere that, oh yeah, you do this to set up. Oh wait, and then there's this other thing. Oh yeah, then there's this other thing you've got to do. Oh yeah, you have to install this. And oh yeah, well, you have to download this. You know, all of these things start coming to mind and becoming apparent that you just gloss over in your mind when you've done it a thousand times. That hands-on work surfaces those learning opportunities that you wouldn't get otherwise.

TAD: Well, I'm curious because we have several people that also participate in the skills clinic; just throwing it out as a question to the rest of you here. What are some of the things that you've learned from skills clinic that you don't get from regular work?

JASON: Right out of the gate, the first thing that came to mind is direct interaction with Redis constantly. And working in a Rails project we just take for granted a gem like ActiveModel and ActiveRecord and how those work together to give you this seamless interface where suddenly you don't have that...you don't even have a database anymore to enforce cardinality. And you're suddenly trying to figure out, okay, how can we implement a model where I just want to implement some sort of find by functionality where I want to find a record of some model by an attribute?

We're getting an introduction to lookup tables. And, again, it's a basic idea, and I think everybody's aware of it. But it's like so infrequently...I've never had to implement a lookup table. And we got to do that together as a group. Tad kind of walked us through the basics of that. So some of the most basic things that are provided to you and you take for granted you have to surrender to that and implement basic functionality so that you can proceed with the project. So that was the first thing that came to mind, no database, having to interact with Redis, and doing everything from memory.

TAD: Yeah, just to give a little context, we're using a gem called Lita, L-I-T-A that was just barely recently abandoned [laughs] but we worked with it, and we're still going with it. And it doesn't have anything behind it except for Redis is kind of the brains or the storage for the bot. And to have something that's primitive is a really interesting constraint.

Because, like Jason said, you don't have indexes. You don't have joins. You don't have a lot of the things that a traditional database will give you. So it's like, I can put data in; I can pull data out. How do we solve these problems? It was a really interesting...just out of curiosity, how familiar are you guys with Redis now as compared to a year ago? Is that something you felt like you've learned a bunch about?

RAMSES: Yeah, quite a bit.

JASON: Yeah, quite a bit more. I'm comfortable with the different primitive data types that Redis supports. But not only that, but a recent problem we ran into was a timeout issue where we would have, you know, we'd ask our chatbot to do something, and in a development environment, it works great. And it would perform its task. It was the expected output. And then we tried doing the same thing from Slack, and it would do the same thing like ten times in a row. And it just kept repeating itself over and over and performing the same task with no obvious reasons as to why.

And I think the problem was that there was a timeout. So Slack was expecting a response or acknowledgment within a certain amount of time. Our main thread was busy, and wasn't able to respond. So we realized, okay, we've got to offload this task and perform it asynchronously. Long story short, we did say, hey, what library exists out there that does thread management better than we could write it and handling locks better than we could do it? Let's implement Sidekiq. So we go and implement Sidekiq.

And there's a configuration problem where, you know, we need an instance of the robot itself that Sidekiq would need to be able to complete the job, so one rolling problem into the next leads to these different design patterns. And long story short, being able to interact with Redis directly where we're able to basically...we don't need to pass an entire configuration to Sidekiq now. We can have a Sidekiq worker write essentially to a response queue. And we can have another loop that is always checking that queue and can read things back. So without being able to interface directly with it, that solution wouldn't have been as obvious. That wouldn't have been a more or less trivial thing we completed in one skills clinic session.

TAD: Yeah, that was really interesting. To give our listeners (I don't know how many listeners we have, maybe just one.) some context, so Slack gives you a WebSocket. So they've got a new API where you basically send some information to Slack and say, "Hey, I would like to connect." And they give you a URL for a WebSocket. And then you connect to that WebSocket and you send a message, hey, I'm here. I'm connecting to this WebSocket. And then you tell your app in Slack (There's a little checkbox list.) all the events you want it to tell you about that are happening in all the channels.

And for all those events that you signed up for, it will send you a chunk of JSON down this WebSocket as one of their event structures. They send you an event, and we had our bot grab that event, parse it, pass it along to all the handlers, and then do a response. We also have to give an acknowledgment back to Slack, like, yes, I got this message, or else Slack is like, oh, you didn't acknowledge the message. I'm going to resend it; I'm going to resend it, I'm going to resend it. And it's going to keep resending it until it sees an acknowledgment.

Well, if you get a message, yes, you can acknowledge it. But then, if you go and do a bunch of work that takes a while, then the next message that comes through, you are still busy doing work, and you won't be able to send that acknowledgment back. And Slack will start doing all these retries on you. And so we realized, okay, we've got this loop that is just checking for events. If we block that event loop, we're going to have to figure out...either store up all these messages or do something because Slack is going to start sending us a whole bunch of retries, and we don't want to do that.

We want to have that event loop looping as fast as we can. And the solution, like Jason said, is let's offload the long-running processes to Sidekiq. And I was actually really thrilled by this because having an event loop and being careful not to block your event loop or [laughs] slow things down in your event loop is actually a fairly common problem. Even on your phone, if you tap a button and if you don't get a response right away, if it doesn't do something right away, then you think it's frozen up. You're like, oh no, I locked up my app.

So responsiveness and making sure that you respond and handle those things right away is really important. But I don't think anyone had ever encountered that kind of a problem in day-to-day work. So I'm like, oh man, yeah, like, making sure your event loop is fast and responsive is a really cool problem to solve. And so I was kind of thrilled that we hit that because then we could talk through it and talk through some different solutions to fixing it.

MIKE: That's really cool. Event loops they're everywhere, right?

TAD: Yeah.

MIKE: JavaScript has taken over the world. In JavaScript, the world revolves around that event loop. [laughs] That's kind of a big deal.

TAD: What else have we done? I'm trying to figure out what are just some of the challenges we've had lately. Oh, one thing I'd be curious to have you guys talk about is your scheduling algorithms that you guys worked out. So a little context before I throw this out is one of the handlers we want to have this bot do is figure out pull requests assignments. So we want to be able to say to the bot, "Hey, I've got this PR that I've just finished. I need reviewers for it. Will you assign some reviewers to it in a fair way?" And it will look through the reviewers.

And someone like me can say, like, "Oh, I'm going on vacation. Hey, bot, don't assign me any PRs for a while." And then when I get back from vacation, I'm like, "Okay, bot, I'm ready to accept PRs again." Things like that. So I'd be curious for you guys to talk about how you figured out that problem.

JASON: Part of the problem with the PR assignments is we have a concept of full reviews and code reviews. So when we get work per project coming through, full reviews typically take a long time. There's a lot of manual testing. You want to make sure that a feature that it could be [inaudible 20:53]. Whereas in code review, you don't need to do manual testing, but your primary focus is on code. Typically, a full review also includes a code review, so it's just more work. And we try to rotate or make those fair.

And right now, it's a random approach. Over time, it tends to even out, but there actually was an issue with our bot assignment basically that we have integrated with GitHub where it wasn't being fair because...it had to do with alphabetical name sorting. So some people, like another developer, we had Steve where we actually have an Easter egg for him in the codebase with a flag [crosstalk 21:31] where that would indicate, okay, we're only going to be assigning code reviews. So if you pass on that flag, we're just going to do code reviews because Steve had discovered this kind of unfair assignment.

So anyway, we decided that there was a lot of work that was done considering how are we going to do this? How are we going to keep it most fair? But in the long run, we have two queues. And we basically came to an approach where we're rotating people through the queues. And we're always checking to make sure that we have the most recent updated list of team members for the given team that were performing an assignment. So that's part of the command we can pass as the team. We update that.

If we have people in the queue that are no longer on that team after the most recent call, we have to remove them from the queue and redistribute that queue in a fair way. And when people are unavailable, that's another thing. You know, we could have people on the team, like you said, Tad, that "I'm going on vacation. Please don't assign me any." You can tell Robbie to make you unavailable, and we'll account for that as well. We have to make sure that it's fair. And then, when you come back, what's the fairest approach to getting full review assignments again or code review assignments. So there are different options and flags that you can pass through.

But queue management has been a big topic that has required a lot of thoughtful consideration and considering different approaches to that. Ultimately, we have a kind of first-in, first-out approach. So it's a general queue structure for these lines, but it's a rotating queue. So anyway, I don't want to get...I feel like it'd be really boring talking about the individual queue structure unless you want to talk about it.

But there's a lot of iteration and a lot of discussion. We probably took probably almost six or seven skills clinic sessions just developing a fair queue structure and then, with every action that you take, making sure that we maintain the fairest approach for those PR assignments. As an aside, from just the queue structure, the cool feature about the PRs and the handler is we've created an API client with GitHub that has all this base functionality built out.

So it's a simple, almost trivial way of once we do that PR assignment, we update the actual description on the PR itself. So the developer doesn't need to add those people. It adds the people to the assignment then adds him in the description with an @ mention. And then, in the Slack channel, we'll use their Slack @ mention name to call their attention to the PR they were just assigned to. So kind of as an aside, and I feel like I'm very long-winded with this, but the queue structure itself that's a problem that I don't think we would have encountered in our core work. It took a lot of thought.

TAD: To me...I didn't work on that directly. Sometimes in the skills clinic, we kind of break into teams and work on our individual parts. For me, one of the more fascinating things was when I learned about queues, it was in a college setting in a class. And they just said, "Here's a data structure. Call the queue. Here's your homework assignment, implement a queue, and implement a queue using a linked list and implement a queue using an array. You'll be graded on it on Friday."

And so we got queue theory, and we got a queue assignment, but we didn't have any use for it. We just kind of did one, and then we were done. And we moved on to the next data structure. And yours was really interesting to me because it came about organically because you were talking about, okay, how do we distribute this? How do we make it fair? How do we do these different things? And it's just like, so we have code reviews, and we have full reviews. What if we had essentially two lines that people were standing in and waiting to be up for these things? And that kind of just matches a queue perfectly. And we've just implemented queues in Redis, and that worked.

The other thing that was really fascinating to me is scheduling problems are, I think, a pretty common problem to encounter just as a developer in general. And to see you guys working through the scheduling problems making sure that, you know, because I learned these things in a formal classroom, and so we learned terms like starvation. Like, what if this job never takes place on accident, or what about all these different things?

And you guys didn't necessarily have that same vocabulary, but you guys encountered the same problem. And you found solutions for the same kind of problems as you would in just regular scheduling. And I thought that was really interesting to just see that just having a real-world project introduced all these concepts to you just organically, and you had to just solve them and work through them just organically. So that was a really interesting thing for me to observe just from the outside.

MIKE: Such great stuff. I'm curious; we have Mark with us, who was part of our inaugural cohort, to say it in [laughs] fancy words. He was part of our first group in an internship that did the skills clinic, and then he's come back. And he's done it more recently. I'm curious, Mark, what parts of the skills clinic have you found most useful that you would recommend other companies implement in order to help people who are wanting to grow their skills, from your perspective at least?

MARK: Hello, I'm Mark. I guess the part that I find most useful is the explanations that my teammates give when they're editing the code right in front of me because they can explain what they're doing, as well as explaining how they've come to this conclusion, as well as other things like explaining how to debug something. Because you can tell someone to debug something and give them tools but giving someone tools to debug something and actually showing them how to debug something and what to look for when debugging something are very different.

TAD: Something that's been funny to me is we usually do a shared session using VS Code, which I think is crazy. Like, I love it that everyone can code and type and talk to each other at the same time. And one person could be working at the top of the file, and the other person can be working at the bottom of the file. But that's just an aside.

What's been really interesting to me is I'll present something, and I'll talk about it, and I'll just be doing my regular thing. And I'll be like, oh man, I need to debug something, or I need to do something. And afterwards, people will tell me, "Oh, I totally learned some little debugging technique," or "I learned some programming technique just by watching you." And it wasn't necessarily even related to what I was talking about. But people afterwards will be like, "Oh yeah, I didn't know Pry could do that." Pry is like a Ruby REPL that has a lot of cool stuff built in. And I'm like, oh yeah, well, I use that every day.

But it's interesting to see just working together with people, with other developers, and you can just pick up on the little things that they do to make their life easier, or make their debugging faster, or something like that. And you could just be like, oh, wow, that's really cool. I'm going to squirrel that away, or I'm going to put that in my toolbox too. That's been really interesting to me.

MIKE: Well, that's interesting. So you're saying that oftentimes, the most valuable...and this seems to be a recurring theme as we've talked about this. Oftentimes, the most valuable opportunities come unexpectedly; you've mentioned serendipity. You're working on a problem, and this side thing comes up, and everybody learns way more from that side opportunity [laughs] than what you had planned initially. You're exploring around, and you find these gems that you wouldn't find if you were just focused on going to your original destination.

TAD: Yeah. And just seeing all the different approaches that people are taking to something has really helped me broaden my thinking about certain stuff that I've been doing as well, which was kind of like a side effect that I didn't expect.

I'm probably one of the more senior people on the team, and I expected it to be kind of like I'm teaching them. But I am surprised at how many little things I learn or understand better just based on what they're doing, or their conversations, or their questions. I'm like, oh wow, I kind of expected it to be kind of single-directional. But we're all working together and teaching each other simultaneously, which has been really fun for me.

JASON: Adding to that, it's one of those environments where I don't think anybody hesitates to ask a question or even to casually [laughs] just be honest and say, "I get that you guys get all of what's going on right now. But I looked up at my screen for 20 seconds to answer a question, and I have no clue what's going on." And everybody having that kind of friendly almost, you know, just pure vibe. We're all working on the same problem. We're all trying to achieve the same objective.

And there's absolutely no problem with someone saying, "I do not understand what you're talking about. Please teach me." That's the entire idea of the skills clinic. And so knowing that that's the entire idea, I don't think anyone's afraid of speaking up and saying, "I don't understand something." And it's led everybody to get a lot closer.

One of the awesome side effects that I've encountered is just another...and this has come up in previous podcasts, but just that getting-to-know-you sort of thing. It's just another avenue where those social interactions are so important because you can't learn from other people if you don't talk to them. [laughs] And you don't talk to them if you don't feel comfortable talking to them. So I often ask everyone pretty much on the call for help independently off-screen people who have been in the skills clinic.

TAD: Yeah, I really like here at Acima; we talk a lot about psychological safety. And I think we even turn that up in skills clinic where we all come in, and we're just like, the whole reason we're here is because we're ignorant about something, and we want to learn more about everything. So there's no shaming. There's no like, "Oh my gosh, you didn't know that?" nothing like that. It's really exciting to say, "Oh, you didn't know about that? Well, this is exciting because today is the day you get to learn about..." and then, you know, something.

We're excited to share with each other as opposed to putting each other down or, I don't know. I'm curious to ask, maybe Eddy, what have you learned from skills clinic, or what things have you gotten out of it? And I'm asking you because you're someone who's in our QA department who knows somewhat about programming but doesn't have any formal programming experience.

EDDY: What I find valuable is how someone uses their resources to find a solution to a problem. It's really easy to get assigned a pull request, but you never really get to see the cycle of what it went through in the back end to get that successful outcome. So I think it's been really integral and critical for me to...or more valuable rather to see the different approaches for individual problems and how they're unique and how we can use you as a resource or the Atlas mentoring channel, or Stack Overflow and such. So to me, that has been super valuable to see how everyone's approach is different.

TAD: Yeah, that's interesting. Something that I've noticed is that it's not lack of skill; it's lack of experience, probably, that slows people down or blocks people. So when I say that, for example, I've talked to you and maybe some of the other people coming in. And if you're new coming in and you don't really have context or experience, so a lot of times you're just like, I don't know, Google, and then, I don't know, Google again. I don't know, Stack Overflow.

And that could take you like an hour before you get to the answer or figure out what you need to do. But if someone else who's familiar with it comes along and is like, "Oh yeah, I know exactly the documentation that you probably want to read," Or "I know exactly which library you could use to fix that or solve that problem," then suddenly, it's like, oh, [laughs] blindly searching for an hour just got replaced with 10 minutes of talking to somebody and getting a recommendation.

EDDY: I just wanted to kind of echo what you said. I think it's...I saw a video from what makes someone successful. And one of those topics was, like, reach out to someone who's in that same profession, who's been there longer. It's like a cheat code, like a shortcut. It's like, you can eventually stumble through that same problem through sweat, and agony, and blood, you know, and stress, or you can reach out to someone who's already been through that map, you know, and cut it significantly to get the answer. So why wouldn't you use someone who has run into that problem? It's like a real-life cheat code, you know.

JASON: [inaudible 35:13] was a senior developer at Acima for a long time. And I had a conversation with him once, and he oversimplified it, or he may have been facetious, but I think there's a kernel of truth in this. He said the only difference between a junior dev and a senior is how proficient they are at finding the answers that they're looking for. They learn to learn better, or they learn to find those answers or search better. There could be a number of different things, but that just came to mind as we were talking about this.

MIKE: More than a kernel of truth. It's remarkable how true that is.

TAD: Well, that's funny because what was it? Like a couple of weeks ago, you were implementing some JavaScript stuff and some marketing and tracking and things like that. And you reached out to me, and I was like, "Oh my gosh, Jason, I've got scar tissue. I've got stories. [laughs] I see you're about to step on a path that I've been down. And let me tell you, it's not pretty at the other end, but here's how it will go. And here's how you're going to get there."

That was just kind of funny to me is that I think we all have scar tissue from some gnarly problems we've had to deal with and a story to tell, and then just like, oh yeah, I see what path you're on. [laughs] Here you go, like, good luck. And here's where you're going to end up.

JASON: Exactly as it was mentioned. It's kind of funny. What you were saying and what you were explaining to me about the problem we were encountering is exactly what was happening. And it sounds like it's just something everybody has to deal with.

MIKE: We've talked about the origin of this skills clinic idea, a lot of things we've worked on, and what has made it useful. And it sounds like, if I were to summarize what I've heard, a lot of what has made it useful is not necessarily the overt this is what we plan to talk about, but the incidental benefits of having developers work together and watch each other and learn. Of course, you can get that from pairing. There are other scenarios that that come up.

But in skills clinic, you're actively going and looking for these new experiences that you might not encounter otherwise. From my perception, I think it's been a very valuable thing that we've done, and I would recommend that others try it. Is that a universal sentiment? Would you recommend that other companies try this idea, start up a skills clinic, you know, and start this daily pattern to improve your skills together?

TAD: Absolutely. I've learned a ton. And I've hit things that I didn't expect to hit and learned things I didn't expect to learn. And like I mentioned earlier, I kind of expected it to be me teaching them, and it's us teaching us, which was awesome.

EDDY: I wanted to say as someone who has a year under their belt as far as learning how to code, it was incremental learning until skills clinic, in which case I feel like my skill has grown exponentially, so yes.

JASON: For those concerned that it's a wasted hour every day, [laughs] you get 100 fold back out of that invested hour. It's amazing how much you can get back. Like Tad was saying, it's serendipitous that you talked about this topic incidentally on Tuesday, and Thursday, that solution came up in my actual work. And that just saved me more than the hour I invested in skills clinic. So it's this compounding effect.

MARK: I think skills clinic is very useful, at least as a coder. For other jobs, they might not do it as often or might structure it differently. But I do think implementing some sort of skill clinic session placed once a week would be good for other companies as well.

TAD: I really like the regularity that we've set up that now I know every day at 10:00 o'clock I'm going to be doing this. I think when we had alternating mornings and afternoons and only some of the days and stuff like that, we kind of lost something. But having it as a regular part of our day and having it as something to look forward to and having it blocked out so we're not having meetings on top of it and stuff like that has really made it much better.

MIKE: And maybe that's a good place to land is that if you want to make this work, you got to be consistent. You should come up with something that you can work on for a while, something out of band that you're not necessarily working on in your daily work to give people different experiences. And just be consistent about it. And we've heard some witness testimonials that it's an investment that has a high return.

Those who are listening who are in a position to try something like this, I highly recommend that you try it. And the worst thing that happens is it doesn't work out for you. But this opportunity to improve the skills of the people you work with and help everybody build them as they have and grow them and become more effective is extremely worthwhile. Thank you, everybody, for being here. Thank you to our listeners. I hope you can put this into practice. See you next time.