Developer Education With Eric Potter

Transcript

Scott McAllister: Welcome to Page it to the Limit, a podcast where we explore what it takes to run software and production successfully. We cover leading practices used in the software industry to improve both system reliability and the lives of the people supporting those systems. I’m your host, Scott McAllister, @stmcallister on Twitter. Welcome back everyone to Page it to the Limit. We are joined today by Eric Potter, director of technical education at Sweetwater. Eric, welcome to the show.

Eric Potter: Hey, glad to be here, Scott.

Scott McAllister: Yeah, today we’re going to be talking about how we train our folks, how we educate our folks. We get smart people into our organizations, but how do we keep them, well, smart and keep them progressing to where we need them to be? Eric’s here to talk about that. So Eric, I want to start off the show with one of our commonly asked questions. And so what are some of the myths or common misconceptions about developer education that you want to debunk?

Eric Potter: The big thing that I have a hard time getting people to understand is even if you work in an organization that has an educator, at the end of the day, it’s still your responsibility as the developer to manage your education. As I try and train our staff and provide training opportunities for you, a lot of times, I’m going to intentionally line up our goals with company goals. The things that I want people to learn are things that line up with what the company’s going to be doing next quarter, quarter after that. And as an engineer, it’s kind of on you to think about, “Where do I want to be? What do I want to know a year from now?” It’s not my job to ask you like, “Oh, what’s your career goals and where do you want to go?” So if you’re a developer that wants to maybe make the transition from web development to cybersecurity, well, you got to own that. Go do it. Think about where you want your own career to be, invest in yourself, and don’t just allow other people to steer you where they think you should go.

Scott McAllister: Such good advice. I was listening to an interview yesterday actually, where someone was talking about how to take control of your career and the fact that the biggest recommendation that this person had, they were a manager, and the biggest recommendation they had was that someone take ownership, they take control of their career, they don’t just sit back and wait. It’s like, “Oh, they’re going to notice my great work and they’ll promote me,” or, “They’ll give me that raise because I do such great work and they’ll just see it.” It’s like, yeah, they might. But odds are, if you’re the one putting, say, in your manager’s ear, saying, “Hey, I would really like to do this,” then your manager’s already thinking about it. They already think about you when they think about those opportunities. And so when you are taking control of your learning, like you’re saying, that probably helps you out. I mean, that way you can help direct where they go or what you teach them. Do you kind of take that feedback from the engineers at Sweetwater?

Eric Potter: Yeah, sure. And I think part of it too is being prepared when the opportunity’s there. So a lot of times, as a developer, you kind of see something coming down the road. I don’t know, 10 years ago maybe Docker was that thing that was just over the horizon and a lot of developers started hearing about it and there’s a lot of buzz about it on the forums or on social media, whatever. And so developers that took that opportunity to start learning about it, start reading about it, start playing with it on their own time, a lot of times that didn’t pay off right away, but as those technologies become more mainstream, now your manager’s like, “Man, we’ve got to do this Docker thing. Who knows it?” And if you’re the dev on your team that’s like, “Oh, I’ve been playing with that in my own time,” all of a sudden that puts you in that position to kind of step up and maybe take point on a technical decision. Maybe it’s the first time you get to be a tech lead or a subsystem lead, something like that. There’s the old saying that luck is what happens when opportunity meets preparation. Yeah, sometimes you just have to be prepared for what you think is going to be big six months or year down the road. I admit that’s tricky. I’ve made the wrong bet. I learned Silverlight because I thought it was going to be big.

Scott McAllister: Okay, my story on that one is Silverlight, I missed on, I jumped in on ActionScript and Flex. I thought that was going to be big. That had the same outcome as Silverlight.

Eric Potter: But I would also argue that those learnings, that adventure, that knowledge trip was valuable to me in other ways. I learned a different platform. I learned more about how user experience works because Silverlight could do some things that the web couldn’t quite do at that time. I learned a lot about what the web could do. And there’s actually another one, this will really make me sound old. I went all in on PalmPilot, read the books, built apps in my spare time, read the IRC message boards or whatever it was. It was big then. And what was interesting was I was doing that before I was doing it for work and we did get a project at the company I was working for at the time as a young engineer. I got to be in some decisions where I was maybe punching a little bit above my weight. I was working with engineers that were much better engineers than me, but I knew the platform like, “Oh, we got to get Eric in here. He knows the platform.” And so I kind of worked my way into some situations because I had done some learning on my own before I needed it for my job. So that was some good experience there that also, I remember the day the iPhone came out like, “Oh, this knowledge that I have in this black and white OS is not going to be very useful anymore.”

Scott McAllister: No, no, it’s not. I think wasn’t a competitor to Palm at the time, wasn’t Pebble a thing back then? There was an OS. I remember I dabbled in trying to get into that space as well. Also aging myself. But it sounds like education for your personal career has been important as you were taking bets on new technologies, but also just seeing the value of the learning process. So talk about, did you start out as an engineer and get into education or how did your road take you?

Eric Potter: Yeah, I was a developer for 20 years in various levels. I was an architect right before I moved into my current role and I’ve developed a lot of different systems, everything from web to mobile to desktop, PalmPilot. I guess that was mobile back in the day. You have various web technologies. I’ve worked with a lot of different clients and a lot of different industries. And it was just always this fun game for me of, “Okay, what do I need to learn for this next project? What do we need to do? What is the new shiny thing and is it worth trying or is it not? How do you spend some time with the technology and figure out if it’s going to be enough? How do you take the lessons from the last platform, the things that you learned from whichever framework you had been using, and imply them in this new framework?” I’ve been fascinated with that all along. And then at some point, I got involved teaching as an adjunct professor at my alma mater. And that was maybe where I learned that I very much enjoyed the teaching process. There is an interesting puzzle to be solved with how do you take this volume of information and try and put it in someone else’s brain and what’s the right order and how do you mix written material and lecture and exercises? I don’t know. It’s fun. It’s also fun. Now I have a lot of my former students that have been in this industry for 10, 12 years. And so it’s fun to see them and their journey and see how they’ve turned out. So when Sweetwater came calling and said, “Hey, we want someone with a lot of development experience, but also has some education experience,” I’m like, “Oh, this sounds really interesting.” I had at least at one point thought about going into academia, but I also really enjoy the practical side of building software and providing value. Not that you don’t provide value as an academic, but there is something engaging about being in the industries, at least to me. So Sweetwater kind of provided the best of both where I could stay technical and focus a lot more of my time and energy on education.

Scott McAllister: So what’s Sweetwater story then? Because it’s an online store for selling musical instruments. How did that come about where they decided they needed to hire someone with your skills? Did they just decide, “Our engineers need to be put on a better track?” What happened there?

Eric Potter: Sweetwater is all about providing a good customer experience. And part of that is we have a lot of custom software. One of the things that we do that sounds silly, but a lot of our customers love it, if you order either audio gear or an instrument from us, you will get a small bag of candy.

Scott McAllister: Really?

Eric Potter: Yes, yes.

Scott McAllister: Oh, I need to be ordering more music.

Eric Potter: And you will get a phone call or a text message from a sales engineer in a couple days that says, “Hey, I saw you bought this. Was it okay? Do you have all the right cables, do you have all the right accessories, whatever?” And sometimes if there’s something for us to sell, certainly we’ll do that but sometimes it’s like, “Hey, oh, could you not figure out how to hook up that mixer? Let me connect you with someone that can setup that mixer.” But one of the things is if we find out what kind of candy you like, we will send you more of that kind of candy in every future purchase. So that means that our customer management system has a lot of very customized fields. It’s not just some off the shelf system. Our order processing system all the way down to our warehouse management system, very customized. I use the candy example because it’s interesting to see where a sales engineer can put that information and I’ve also been out in the warehouse where the person packing the box will get the little pop-up notification that says, “Scott prefers a bit of honey, right? Put some more extra bit of honey in there.” All that to say, that’s a very long introduction to say we have a lot of custom software all over the place. The website is highly customized.

Scott McAllister: How many engineers? How big is the engineering team there at Sweetwater?

Eric Potter: It’s north of 200.

Scott McAllister: Okay. So that’s a lot of engineers riding a lot of custom software.

Eric Potter: And a lot of different platforms. And so as we continue to grow, there’s this perpetual demand to try and keep up with the latest technology. And then also, like every other software shop, we have to hire because there’s continual movement. And so it just became apparent before I was hired on that they needed someone to manage both that onboarding. There’s a lot of education we do when someone joins the org and how the organization works and what our philosophy is and what systems we have in place. And then also once someone’s in the organization, technology is kind of a treadmill and there’s always something new and there’s always something better. And so they decided they needed someone to keep an eye on that, to do some of the training or in a lot of cases, just coordinate the training. I certainly am not an expert on all of the technologies that we use. That would be impossible.

Scott McAllister: I was going to ask that because that would mean you’re pretty amazing. I mean you are amazing, but I mean you would have a vast amount of knowledge over the whole industry. So how do you handle that? I how do you decide on topics and then who does the teaching?

Eric Potter: Good question. So topics are almost always tied to what our upcoming quarterly goals are. So I’m looking at what are we trying to achieve three months down the road, six months down the road. And I’m not making the decisions about what we’re trying to achieve, but I’m kind of following the lead of the business. So I’ll give you an example. We have some systems on the website that aggregate a lot of data and need to report on that in not real time but rather quickly. And so we had services that did that, but we were running into some performance issues. And it wasn’t even that the code was inefficient, it’s just that they’re in interpreted languages and there was just a bottleneck that we’re hitting because it was interpreted. So we decided that we needed to reimplement some of these microservices in Go and so there’s kind of one team that spearheaded that. They’ve migrated a lot to go, they’re getting much better performance characteristics. Well, that was so successful that now we’re saying, “Okay, well, where else can we apply that learning?” So actually here in fourth quarter, we’ve been doing a lot of additional education. I can write some software in Go, but I’m probably not the expert in it, but I know who is, I know who in the organization is that person. And so then it’s a matter of coordinating when can I get the technology expert in a room with the people that need to learn to reinforce that more classroom style learning. Then we followed that up two days later with a hackathon where the rule of the hackathon was you have to build this app in Go. So you now have some theoretical knowledge, you’ve written Hello World and your first web service. Okay, now actually try and build something with it. And me and my team, we coordinated all the logistics around the hackathon, provided some learning materials, but I didn’t necessarily do any of the teaching directly for that one. There are other times where I am the teacher, but specifically in this case, there are people that are better suited to teach that than me. So I’m just connecting the pieces. Here’s the people that need to learn and here’s the person that’s the right instructor.

Scott McAllister: That makes sense. And your approach, it’s the continuous improvement type of approach. You try to go on a little thing, a little service, and it’s like, “Wait, wait, this is actually working. This is something we need now. We need to spread this knowledge throughout the organization.” So you’re like the person that basically you sit in with engineering and you’re like, “Okay, yeah, this is big, this is successful.” Or actually engineering probably sees that and then says, “Hey, let’s bring in Eric and start figuring out how to disseminate this knowledge throughout the rest of engineering.”

Eric Potter: It’s a little bit of both.

Scott McAllister: Okay.

Eric Potter: Because sometimes people come to me and they’re like, “Man, we just had this huge win. We leveraged such and such a tool, we’ve got to get this out to more people.” Sometimes it’s that I am meeting with multiple different teams and I’m hearing what they’re struggling with and it’s like, “Wait a second, did you know that we solved that exact same problem three months ago in this other part of the business?” Then it’s connecting people or, “Hey, we just need to get a mob programming session with these two teams together and just see what happens.”

Scott McAllister: Is most of the material and types of things you do in person or do you also help make resources available, say, if the organization is moving to React or something like that and you want to say, “Okay, well, here’s the resources we recommend you getting started with first and then we will have a thing?” Or is it more of a, “Oh, this group needs to learn React? Let’s bring everybody together, let’s find a time, let’s get a room, let’s get everybody in that room, and kind of do a in-person thing or online type thing?”

Eric Potter: Good question. So when something is not proprietary to us, there’s very little value in me recreating the wheel or anyone in Sweetwater recreating the wheel. So let’s stick with React. If I have a team and they say, “Hey, we need training on React,” then my first thought is going to be, “Okay, what resources can I get?” We have a Pluralsight subscription, Cory House’s courses on React are first rate. I might even recommend the videos. I might be like, “Hey, I know these courses are good. I’ve had success with them in the past. I know this trainer’s good. Just go watch those.” There’s no sense in me competing with that. But a lot of times the training that I’m doing is, “How does this technology fit in our context?” It wouldn’t make sense for me to do training that was very specific to Git, right? There’s good resources out there. We use GitLab, not GitHub or any other things. So there are some times where it’s like, “Oh yeah, there’s maybe not the same level of documentation about how to do this thing on GitLab.” So then we’ll create that. But yeah, always my go-to is going to be, “Are there good third party resources for this?” Whether or not from one of the online platforms or from an independent vendor or are there good books or whatever? But the thing that I really enjoy is in, “Well, what are the activities that we can layer on top of that?” Now you’ve gone and watched video or read a book or whatever, but now let’s put together some kind of game. Let’s gamify it somehow. Let’s do a hackathon, do some kind of clean code contest, whatever it is, to try and then cement that learning and take it from just information to like, “Okay, this knowledge is now in my hands. I can put this on a keyboard.”

Scott McAllister: Yeah, let’s apply what we’ve learned. I mean I learn by doing. I can read something, I can see something, but unless I’ve done it, I probably won’t remember it. That makes a lot of sense where you want to give them the resources. So it sounds like you’ve essentially vouched for the third party resources, which again is smart because that’s already there. They’re proven industry people like Cory House, like you mentioned, and then you could probably say, “Well, at Sweetwater, for our stack here, you’ll want to watch this section and then skip over to this section and then do these ones.” Rather than being like, “Yeah, do this whole 27 hour course.” Actually, you only need nine of those 27 hours. The rest of it is good, but it’s not exactly what we’re doing here.

Eric Potter: Yeah, exactly.

Scott McAllister: That makes a lot of sense there. And then getting folks to just get hands on keyboard and actually do the knowledge and to cement it in their brains. What would you say is your biggest challenges as a developer-educator inside of a corporation like Sweetwater?

Eric Potter: This will sound really lame. Coordinating schedules. It’s not like I’ve got a whole bunch of engineers that have nothing to do, so what’s the right time to find…? Can I do this over a long lunch? Am I trying to get people here on a Saturday? And then finding the right mix of all those things. We do continuous education at lunch at least once a month where there’s a big meeting and either someone internally or sometimes someone externally is coming in to do some teaching, done a couple conference attendee things where we’ve taken people to a conference on a Saturday where someone’s willing to give up a Saturday. Some of it’s during work hours when that’s appropriate. So finding things that work for different people. Some people can give up a Saturday, no problem. Some people can’t. That’s not me saying anything bad, casting shade on them, their life situation. And they should deserve to be able to learn in their time too.

Scott McAllister: And you bring up a good point with coordinating schedules because as we’re recording this, this is the holiday season here in the United States, and so schedules get even more crazy and especially for an organization like Sweetwater, which does e-commerce. And so your big time season is now, how does that affect training and education for you and your team and for your company? Is that when you schedule things or is that when you avoid things?

Eric Potter: So being in IT, especially for a company that a huge percent of our revenue comes from e-commerce, really for us, the crazy season is probably those six weeks leading up to Black Friday. So I would say that was the time where we maybe spun down some of our training and education efforts because engineers deserve to have their full focus on whatever their problem was they were trying to solve or whatever value they were trying to provide before Black Friday. So now we’re in a situation where we’re kind of on the down slope of that wave a little bit, the systems are now in place, they’re all working, and so we have had a chance to try and catch up and do some educational things, trying to squeeze in this window between Black Friday and Christmas. Even then, I think I mentioned we had this hackathon the other night and I knew when I scheduled it, anything on an evening in December is going to be running into somebody’s Christmas plans.

Scott McAllister: Yeah, especially in the evening. This is definitely showing commitment that you’re going to come in off hours to work on this.

Eric Potter: You came either in to learn more about Go or the pizza. We order really good pizza.

Scott McAllister: Oh, well, I would probably be there for both because I like Go but pizza will definitely drag me into a place.

Eric Potter: And I will say one of the things that somewhat surprised me about the hackathon, and I didn’t realize it till I was in the room, was there was a lot of learning going on that was not specific to the learning objectives I set out. So the main reason that I on behalf of Sweetwater wanted to have this thing happen was so that we would have more engineers that are competent Go developers. What I saw happening was a lot of people saying like, “Oh, I didn’t know you could do that in that editor,” “Oh, I didn’t know that you could debug that with this tool.” The hackathon challenge was to build a bot for Slack. And so I’m watching a lot of engineers teach other engineers how to use Ngrok so that they could debug their bots. And so it was really kind of interesting to watch. Man, there’s a lot of learning going on in this room that I didn’t even fully intend. Sometimes you get the right people in the right room and it’s not even so much about teaching, it’s letting that knowledge kind of flow in between all the people.

Scott McAllister: One of my first experiences getting involved with community, which I didn’t quite understand it as community at the time, it was the first time I attended, we called it a user group back then. It was a ColdFusion user group, dating myself a little bit again, and I walked into the room, I don’t remember anything about what they presented that day, but what I remember is that the presenter’s first question was, “Who here is still using HomeSite?” And put my hands up and I realized me and the guy next to me were the only ones doing it and the guy in front of us turns around and goes, “Oh.” And that’s when we are like, “Oh.” And so then we start talking to everybody in the room and it’s like, “Oh, they use this and they use this.” At conferences nowadays, they call it the hallway track, right, where we share that knowledge with each other just by being in proximity of one another. That is where a lot of my learning has happened, where I’m in proximity with smart people and I’m like, “Oh, they do something a little differently or just a little bit better than me on this. Let’s pick up with that piece.”

Eric Potter: I don’t know if you’re familiar with some of the writing of Jeremy Clark on what he calls being a social developer, but over the years, I’ve learned a lot at conferences and I’ll give Jeremy all the credit. I follow his playbook to a T.

Scott McAllister: Jeremy’s awesome, people should definitely check him out.

Eric Potter: He might have socialdeveloper.com, whatever it is. If you Google it, you’ll find it. But this idea that if you’re at a conference and you’re in line for lunch and you turn to the person next to you, you’re a developer, they’re a developer, probably neither of you wants to start that conversation, but if you say, “What kind of code do you write?” It’s a simple question, they’re going to have a long answer. And I have learned a lot that way. I remember, I think it was at Beer City Code four or five years ago, I was in line for lunch and I turned to the guy next to me and said, “What kind of code do you write?” And he’s like, “I write PHP.” And I don’t remember what I said, I’m sure it was kind of snarky, and fortunately-

Scott McAllister: As we do, yes.

Eric Potter: Yeah, fortunately he’s like, “I’m going to guess that you haven’t written PHP in five years.” I’m like, “Probably more like 15.” And he is like, “PHP has become a good language.” I’m like, “Okay, I’m game. Tell me, convince me.” And standing in line at that conference, he changed my mind. PHP has gotten so much better and had I not been standing next to, and I have no idea what his name is.

Scott McAllister: right.

Eric Potter: I have the impression but I can’t remember who he was. And I learned a lot that day. There are other things I try and do to recreate that in the work environment. Have you heard of Lean Coffee?

Scott McAllister: I do believe so. But remind our listeners, what is Lean Coffee?

Eric Potter: So Lean Coffee is a meeting format where you invite a bunch of people. There’s usually like some general topic and you invite a group of people. The first couple minutes as people are coming in, hand them post-it note or stack a post-it note, say, “What topic do you want to talk about? Write on the post-it note.” And then you put them all on a table and you group them. So if three people said they want to talk about Kubernetes, you put them together and everyone takes their Sharpie and they look at this collection of post-it notes, and then you put dots on whichever one you want to talk about. You’re given three dots. And so then after a couple minutes have transpired, whoever’s the coordinator picks up the Post-it note with the dots and says, “All right, we’re talking about this.” Then you set a timer or you can find apps online that will help you with this. Set a timer for five minutes. At the end of five minutes, wherever the conversation goes, that’s where it was supposed to go. The timer goes off and everyone gives you a thumbs up, thumbs down. If the majority of the room say thumbs up, you keep talking about it for four minutes. If it’s thumbs down, you go onto whatever topic has the next most votes. And if people continue talking about it, you do the five-minute block, then four, then three, then two, then one, if you get to the end of that, then it’s like, “Yeah, that was all we need to talk about there.” But it’s a really interesting way to learn because the conversation organically goes to whoever’s there. So you’re not trying to pick a topic and then try and get the right people in the room. It’s like, “Well, let’s get some people in the room and just see what we can learn.” I have learned a lot in this format over the years. We’ve done a couple, at least one of these this year at Sweetwater, when the ThoughtWorks Technology Radar document came out. We reserved a room, like, “Hey, at this time, show up in this room. Read the document beforehand and then let’s discuss what we want to discuss.” I would’ve not guessed that we’d have had a long discussion about container security vulnerabilities, but we did. And it was actually really interesting and really thoughtful, and I learned some things from some people there that had done more research on that. And sometimes just getting people in the room around the right topic, finding ways to get them to talk to one another is incredibly educational.

Scott McAllister: Indeed. So in an ideal environment, what does the ideal developer education setup look like? Or maybe a better way to ask this is it’s a common thing we ask in business, what does success look like? What does success look like for a developer education team? Is it the fact that everyone, I mean, knows everything? I mean, yeah, what does success look like for you and your team?

Eric Potter: Yeah, ideally, I don’t know in some parallel universe, maybe there is a chance that you could know everything and technology grows so fast, there’s just not enough hours in the day to know all the things about all the things. And so I think success looks like the teams that I’m serving, achieving their goals. Let me give you another example. We had a team that was transitioning from Objective-C and Cocoa to Swift and SwiftUI, and they had some goals for what they wanted to accomplish, but they also wanted some help coming up with training materials for specifically SwiftUI. They actually had done some learning on their own on Swift. And so I tried to put some things together where it’s like, “Hey, I’m going to help you accelerate your learning.” But the payoff for me was that they shipped that app when they were supposed to ship that app. And so as the educator or the education coordinator, my goal is to help my teammates achieve their goals. So if I’m giving them enough information to do the things that they need to do, then I’m being successful.

Scott McAllister: Sounds a lot like a developer advocate facing internally rather than externally. It’s kind of a lot of what we do and what our motivations are. My motivation as a developer advocate, we say we want to make developers rock stars essentially. We wanted to give them the tools and the education they need to be able to use whatever technologies that we’re advocating for. That rings true for me from what you’re looking for.

Eric Potter: And I imagine there’s a lot of overlap there too, in making use of all the right mediums. Because I will sometimes hear people say, “Oh, going to a conference is so much better than reading a book, it’s so much better than doing a tutorial.”

Scott McAllister: For the different person, yeah.

Eric Potter: Well, but it’s different per the context. So there is a time and a place to learn something just enough to know if it fits in your context. So I might think that Elixir is a really interesting language and I should go learn about it enough to know if it applies in whatever my developer context is or not. There are technologies out there that I have a lot of respect for, but because of, I don’t know, what libraries they have or what tooling they have or whatever, it’s just not going to work. Sometimes you find something like, “Oh, that actually is really useful,” and it slots in really nicely. And I’m thinking 10 years ago when I was first learning about TypeScript and you realize like, “Oh, I just have to set up my tool chain correctly and this becomes JavaScript and I can use this everywhere. Awesome, this is amazing.” I like things like conference talks for the, “Why should I care about the thing?” I think written documentation or video documentation is really good for, “What is this?” And “How do I use it?” But then again, kind of comes back to you have to have a hands-on keyboard piece of this before it really becomes useful. So mixing all those things, mixing video, mixing conversations, mixing in lectures, it’s all plays a piece and it’s playing the right piece at the right time.

Scott McAllister: Like a conductor?

Eric Potter: Yeah.

Scott McAllister: So we have a couple of recurring questions we like to close episodes with, so I’d like to see what you have to say. What’s one thing you wish you would’ve known sooner when it comes to developer education?

Eric Potter: I wish I had known how much time I would spend in Outlook.

Scott McAllister: Yeah. Goes back to that scheduling bit, the biggest challenge is really just getting people in the same room.

Eric Potter: And understanding what people already know, understanding what people are trying to do. Sometimes you’re like, “Oh, we should do a training on this thing,” and then you find out like, “Oh no, we’re ditching that next quarter and we’re going to the next thing.”

Scott McAllister: Yeah.

Eric Potter: So yeah, a lot of time, writing emails, we use Slack, so a lot of time in Slack.

Scott McAllister: Yeah.

Eric Potter: I joke there are days when I think I spend more time in Outlook than I do in an IDE. Sometimes it needs to happen.

Scott McAllister: It’s the sad truth. Even engineers, I’m sure there’s some engineers that that happens some days.

Eric Potter: Yeah.

Scott McAllister: Is there anything about developer education that you’re glad we did not ask you about?

Eric Potter: I think the squirreliest bit is how do you educate someone that’s not motivated? I’ve run into this teaching at the university level. For years, I’ve had teammates where, “Hey man, you could learn this thing and this would be really good.” “I don’t want to learn the thing.” And again, I fully respect someone that their hobbies are somewhere else and they just want to work their allotted hours and then go do something else. If that’s what you want to do, more power to you. But sometimes it’s like, “Man, you could really be moving along in your career. You could have more job satisfaction if you would just invest more time in this, invest some of your own time in this.” I personally struggle because I really enjoy learning. I’m the engineer that reads about something on Hacker News or Lobsters and I’m like, “Oh man, I got to find some time Tuesday night to go play with that.”

Scott McAllister: Yeah.

Eric Potter: I’m not trying to make a value judgment about people who are willing to invest nights and evenings versus people that don’t. But again-

Scott McAllister: There’s got to be some motivation.

Eric Potter: If you work in technology, it behooves you to keep up with technology. And I’m probably preaching to the choir because whoever’s listening to this is listening to a technology podcast, so good for you.

Scott McAllister: Right.

Eric Potter: But yeah, that’s maybe the squirrely bit. I don’t have a good answer for it is like how do you motivate someone to learn that’s not motivated.

Scott McAllister: Well, and that’s a question that’s bigger than software.

Eric Potter: Sure.

Scott McAllister: It’s all throughout our society and any industry. But Eric, we appreciate you coming on today. Thanks for sharing your knowledge about education and your experiences.

Eric Potter: Glad to do it. This was fun.

Scott McAllister: Awesome. Thank you all for listening. And this is Scott McAllister and I’m wishing all of you an uneventful day. That does it for another installment of Page it to the Limit. We’d like to thank our sponsor, PagerDuty for making this podcast possible. Remember to subscribe to this podcast if you like what you’ve heard. You can find our show notes on pageittothelimit.com and you can reach us on Twitter @pageit2thelimit, using the number two. Let us know what you think of the show. Thank you so much for joining us. And remember, uneventful days are beautiful days.