51. Evolve or Die – The Importance of Continuous Learning

Rich: In episode 51 of Mobycast, we talk about the importance of continuous learning for both the software developer as well as the organization in general. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. Let’s jump right in.

Jon: Welcome, Chris and Rich. It’s another episode of Mobycast.

Rich: Hey.

Chris: Hi guys. Good to be back.

Jon: Yeah, excited to have you here today. We haven’t done this in a while. Just tell me what you’ve been up to this week, Rich.

Rich: About a week ago, I started just playing around with this side project. We’re trying to create more efficient processes on how we can get designs approved in the browser, so I tried to build an app within WordPress to do that. It really wasn’t meant to ever be anything and then two days later, the half finished and something that I’m excited about. Doing a web app in WordPress is probably the wrong platform to do it in, I know. It’s what I know and it will be functional, and something that we can use internally as an MVP to see if it’s something worth rebuilding into maybe a more applicable framework.

Jon: Yeah, sounds cool though. Sounds like you’re probably learning some new stuff, making something new?

Rich: Yeah. It’s keeping me up at night, not a bad way. It’s been a decade since I stayed up late writing code and I’m doing that again. It’s interesting because I’m not feeling the fatigue that I wouldn’t have expected or that I normally get for staying up late because it’s energizing.

Jon: All right, that’s great. How about you, Chris? What have you been up to?

Chris: I’m back in the office this week after doing some traveling last week. I was out in Phoenix, Arizona for another one of the AWS certification item writing workshops. Again, fortunate to participate in writing these exam questions for the certification test that Amazon has. It’s good refresher for me and also it helps me prepare. I’m studying for the professional level exam.

Jon: Every cloud guru is listening. They just desperately want to talk to you about the answers now. Sorry.

Chris: Indeed they are.

Jon: I noticed a theme there. Both of you are working on some of these stuff, learning some new things, and that’s what we’re going to talk about this week. We’re just going to talk about just the importance of continuous learning in this industry, and just kind of evolve or die, not mindset, not ethos, but just reality of working in software. You do get booted out of software, or at least booted out of the well-paying fun part of the dream of the software career if you don’t evolve. There maybe some people out there that are still hanging on their laurels of writing COBOL code but I imagine they’re not having as much fun as people do in coding stuff in the cloud.

Chris, you could tell us a little bit about what have this all came up and why are we going to do an episode on it today.

Chris: What happens, Rich and I were doing a little chit-chat while preparing for the previous episode of Mobycast and I talking about me going out and participating in this workshop for AWS to write these exam questions and explaining just what it was. It’s actually super challenging because your in a room with mostly AWS employees. Most of them are doing solution architect work as their career. They work for AWS. There are like super hardcore experts. So, being in the same room with them and trying to level-up, it definitely keeps you on your toes. It can be humbling but it’s also very rewarding, too, because you get to learn.

That sparked this conversation with Rich where that’s definitely one of those key principles that Rich himself holds dear. Maybe have Rich talk a little bit about his perspective on that and how it grew into this talk.

Jon: Yeah, Rich was one of the things he said to Chris. Tell me again, you don’t get paid for this?

Rich: I don’t think I said that. I think I was excited to hear that and I think it’s because one of my core values is lifelong learning. It’s not the case for everybody but in our industry, it’s important. What I liked about it was it all predicated from the fact that three or four years ago, Kelsus was a Rails shop primarily and since then, you guys has transitioned into a full-stack Javascript agency.

That’s not an easy transition and you have to be pretty nimble and willing to go through that transition because there’s a lot of work involved, there’s a lot of headache, it’s painful for the staff that needs to do it, but you did it anyway. It was the most important thing for you so you did it. It’s interesting because there’s a lot of really, really smart people, really, really established agencies like Kelsus who won’t do that.

That’s the thing. You can’t just jump every time something cool comes around. Like today it’s React. Will it be tomorrow? Maybe, maybe not, but at some point you’ll have to say, “We got to go all in on this, otherwise, our agency or our brand is going to fail. How do you know when to make those decisions? What is it going to take to make those decisions? And what kind of culture do you have to embrace those decisions when the executive team says, “Okay, now do this”? You guys usually aren’t the ones writing all the code for it.

Jon: Right and I think part of what we’ll get to today is that with our continuous learning mindset, that one thing you just said that could give some of the anxiety like, “When do I know when I should do this?” like, “How do I know when to make this bet?” I feel like the answer is, if you are constantly learning, constantly paying attention, and doing stuff, it will just be obvious. It will just be like, “Oh, God. We got to do this,” like, “No, full stop. We’re doing this.” It’s not a, “Is this right? Is it going to change? I don’t know.” The trends in the industry are very, very clear to people that are learning and paying attention, I think.

Rich: What about someone like DHH? Creates Rails, is probably never going to leave Rails, needs to maintain it for the community—I guess he doesn’t have to but he probably will—37signals and Basecamp, all their products are on that stack, he’s a lifelong learner, too, but he’s not going to change. They’re not going to change, or are they?

Jon: I think that it’s just a really different position to be in when you have customers and people relying on something that you’ve built, and in that case, you have a responsibility to that. If you were to leave and then say, “I’m off. See you. Javascript time for me,” that would be pretty awful.

Rich: Yeah, exactly. Some people are actually locked into this regardless of the […] tank.

Jon: Right. Let’s talk about the rate of change a little bit in the tech industry. What some of the things that we do or need to do, some of the things that people, in general, need to do in order to keep up with it? Chris, go ahead and just start about that rate of change and what you’ve seen over the past 75 years.

Chris: Thanks, Jon.

Jon: I can’t give a real number so I gave a fictitious one.

Chris: It’s even higher number than that. Obviously, no big surprise. We’re not some grand prognosticators here saying that technology is changing very, very fast. Not only is it changing fast but that rate of change is even accelerating. We’ve talked about this before. Just looking at, say AWS and the features and the services that are getting rolled out each year. That just continues to grow tremendously, quickly, and it’s like drinking from a fire hose trying to keep up. And it’s just not AWS. Obviously, it’s the entire technology landscape.

There’s plenty therefore to learn, to keep up, to basically just keep your education, your training, your skillset fresh, and it really is one of those things, in order to continue to stay relevant, you have to. It’s almost like becoming a requirement. I think it’s a harder requirement now than it was even 20 years ago because I think that rate of change is accelerating. So 20 years ago, you could basically milk your existing skill set and stick with that pattern of like, “Well, this is what I’ve always done and it works. That had a lot longer shelf life 20 years ago. It doesn’t have much of a shelf life today.

I think this idea of continuous learning and really paying attention what’s going on in there, rolling up your sleeves, just building things, doing things is just becoming more and more important for you just to stay relevant, to be able to do this. Otherwise, you end up just withering, risk to be marginalized, and then you have to find other things that you can do. Maybe you transition more into soft skills or management, if that’s what you want. They maybe just fine, but if you want to stay in tech and do the work of tech, then continuous learning is just an absolute must and being strategic about picking what it is that you do. Rich touched on this a little bit with the questions of like, “When do I adopt this or that?”

One thing I really believe in is that it’s not important that you stay at the bleeding edge of technology, that’s not what’s important. What’s important is just being abreast and knowing what’s going on. I think it’s very pragmatic and smart to wait and see how things play out because there is so much churn and there is so much innovation, and a lot of it either doesn’t make sense or it peters out, and there’s just too much of it.

You can’t go and do everything but if you keep an eye on it, you watch it, you wait, and you have a trailing edge of adoption, say it could be like a two-year trailing edge, that’s still a great thing. There’s nothing wrong with that. CICD may have been really popular and people started really talking about this in 2006, or 2007, or 2008, or 2009, or 2010, or whatever it was, but still pretty difficult to do and adopt. Now today it’s plain dead simple. There’s no excuse for not doing it. There’s some place in between there where it makes sense to say, “Okay, yeah. I’m going to go start doing this.”

Jon: I want to add to the ‘how do you pick what you learn’ piece. I don’t know how to quite describe this but for me I have this feeling of marginal returns on learning. I’ll learn something at a high level and get a sense for what it is, and then start digging deeper and deeper until it feels like every new thing I learn about is producing fewer results, like every extra hour I spend is not really giving me that much more capability or knowledge or information that I can actually use today. So I try to keep my learning at that level until I’m ready to actually do something with that particular technology. It’s abrupt first approach to technology learning when going just deep enough to get to that marginal returns point and then moving on to the next thing that I want to find out about.

I think that’s a part of it and I think another part of it is just like picking your layer of abstraction. So, do you want to be more focused on what’s happening in the cloud or do you want to be more focused on what’s happening to CPU architectures? There’s stuff happening in both places just recently and now some new enclave technology that they have for secure processing. That’s really important to people working on things like Docker, the actual container stuff, the code that creates containers. They care deeply about that. But if you’re building business software, maybe you don’t really need to know anything other than, “Oh yeah, that thing came out. I can just read one news article about it and move on.” That’s my approach. Do you have a similar approach, Chris?

Chris: It’s a smart strategy and it’s a necessary one, again we talked about. There’s so much going on. The armies of people working in the industry and innovating, they’re getting bigger and bigger. So you have to kind of specialize. You have a limited amount of personal bandwidth and time, so be smart about it. Don’t be paralyzed by having to be overwhelmed by everything there is to be learned. Pick the stuff that makes sense for you, your interest, your career, where you want to be, and yeah, you’re going to have to do some specialization. Go broad and ticket that survey and landscape of what’s going on, and then you have to be careful. Pick and choose where you want to go deep.

Jon: Another thing that I’ve seen that’s interesting, that’s happening recently, and maybe just my perspective on it, it made me realize that those of us that are, I don’t know, Chris and Rich and I have age over 40, have this weird advantage because we learned computers when they were kind of knowable. Like when Microsoft would release a new operating system, you can know all about it, all the new features, you can keep track of them. A new programming language would come out, you can learn how to use it in its entirety. It was basic.

What else? Just the whole thing, like how networking works, how computers work, all the way down to their architectures, RISC versus CISC, all that stuff. That was always available to us. Then as things got more and more complex, we just have this luxury of just taking on new knowledge on top of the existing knowledge and the great this is that all that new stuff does depend on all that old stuff. Do you secure enclaves in Intel chips? They’re making use of principles that have been around for a long time.

This is the interesting thing I’ve seen is that I’ve noticed that some notable developers in the internet world, one that particularly come to my mind is Jessie Frazelle, she’s been unemployed recently and has taken some time to just dig deep on some of the more computer-y stuff, computer architecture, and how deep down systems work. I think she’s going in that direction from previously been more of a web developer. I’m seeing it’s not just her. She’s inspiring other people to go and take a look at computer history and think about systems architecture, just early days and how things were put together. People are reading these books that she’s been putting on her book list.

It’s like this generation that came after us, who hopefully are listening to some of the things that we’re saying on this podcast right now—I hope I’m talking to you—is like taking a trip through history to pick up the things that we were just lucky enough to have grown up with. I just think that’s super fascinating and it’s part of this learning culture. It leads to another big point we want to make on this podcast, which is just that pattern. What do you see is the typical pattern for people in this industry as they mature and go through things?

Chris: I think it’s been pretty traditional and people in their early career are the ones that are software developers, writing lots of code, working late, pounding the coke, eating the pizza, that is the stereotype. To some respect, just the idea that coding is really for the younger people and as you get older, that’s something that folks transition out of. It is true in general, especially with software development. As people advance in their careers, less and less of them are actually doing software development and that they’re being promoted up, if you will, through becoming managers and doing that.

Jon: I’ll add one piece of color to that. I have just looking for this article and maybe we can add it to the show notes but I was reading an article about, “Why wasn’t I chosen for principal engineer?” The whole article was like you […] Trello cards better than anybody else in the team is not what makes you a principal engineer. I would agree with that. We do expect somebody who is a principal engineer to have an influence on the entire development team and across organizations even, just in the entire technology practice within the company. But that implies some soft skills and some management skills that are different than just pounding the code. Inherently, there is an expectation that even if you stay a doer and an individual contributor, that you do grow beyond that.

Chris: Yeah. Again, if you have pure hard skills, you’re only going to go so far in the industry. Some skills are super important. Things like being able to mentor, to be able to instill that culture of learning or the rest of the organization to do the influencing, to operate at the architecture level, all of that stuff is super important, really hard stuff to do, but you also have to be super technical as well. You still have to be a doer, you still have to be hands-on. You can’t just not put in the work. It’s just as hard to operate at that level and requires just as much diligence and time as it does at just banging out code.

Most people, I think, in this industry don’t follow that trajectory. More like, “Okay, I’m no longer going to be hands-on coding. I’ll do some managing, I’ll be a middle manager.” They’re not really staying fresh. They’re really just doing the process and not really evolving. That makes them become less and less valuable to their organizations and that’s when you really start running into trouble. We have to improve both our hard skills and our soft skills. As you strike that balance, you become much more valuable, and that’s a great place to be but it still requires a lot of effort.

Jon: Right. There’s sort of classic joke that I hear a lot. “It’s been years since I touched code.” You’ll hear this on conference calls a lot but it’s a way of trying to signal, “I once was technical and I can still talk the talk but it’s been a while since I’ve had an IDE open.”

Chris: Yeah. For me, I think one of the primary indicators is just how comfortable am I? I think this a good gauge for everyone. If you’re really comfortable with what you’re doing day in and day out and you’re kind of on autopilot, it’s easy, it’s just one pleasant autopilot mode. That’s a huge warning sign, like “Danger, danger.” That’s a very clear indication that you are not growing.

Change is hard. It’s uncomfortable. We as humans resist it strongly and it’s difficult. It’s painful, it requires effort, but you should really strive to have more of that in your life. If you are, that probably means you’re doing a good job of evolving, employing that continuous learning, and you are growing. You need some of that discomfort in your life. Don’t settle in.

Jon: Right. You essentially have a growth mindset. Chris and I, Rich, have been preaching to each other’s choir here. We both agree on this. Is there anything that you have heard here that strikes you as different or new or anything that you’re doing is counter to or in agreement of what we said?

Rich: I have a question that will put you on the spot and you’re probably not prepared for it. If we understand that continuous learning is imperative for a company, that also means it’s imperative for the company culture. How are you empowering the staff at Kelsus to continually learn? What are you offering to them to make that possible?

Jon: That is a great question. This podcast for one is like, “Hey, everybody give us a listen because we talked about a lot of the stuff that we care about and some of the things that you’ll hopefully hear on this is like we’re your professors. Learn from what we’re telling you. That’s a little thing.

Another thing that we recently just did was we try to evaluate some learning platforms. We look at Pluralsight and it looked pretty good. If anyone from Pluralsight is listening—please I hope you are—we ended up getting all the way through the sales process with them and then finally rejecting them because I personally was so appalled at their high-pressure sales tactics that I just finally blew-up the deal. I was like, “I’m not going to talk to you anymore.” So, we’re going to find another learning platform other than Pluralsight. Anybody that’s writing me emails at 9:30 at night or 10:00 at night saying you only have two more hours to sign the contract before the deal goes away, F you. You’re dead to me. That’s Pluralsight.

We’ve also been using A Cloud Guru which we’ve talked about before in this podcast for learning about the cloud and getting prepared for certain occasions. We’ve had a couple of people go through A Cloud Guru courses too, and then actually achieved AWS certifications which is super cool to see. I love seeing people at Kelsus get certified in AWS. And then also Udemy and Udacity, we pretty commonly use those for learning little things.

The other thing that we’re trying to do is—this is an experiment but we talked about this recently in the podcast—I’m putting together this open source project that’s big enough for everybody in the team to contribute to, and I’m hoping that by leading by example like, “Hey, look. Your leader is literally writing code and literally putting this out there for the world to comment on and talk about. You should be doing the same.” That hopefully will be like a light for people to see, like, “Oh, yeah. Look. Even Jon does some coding, opens the IDE and works on stuff.”

Chris: And the other part of that too, Rich is you can foster continuous learning by literally just pushing your team over the edge. I think we’ve done that at Kelsus as well. This transformation from a mobile path only shot to something that’s more full stack and into the cloud, understanding more about distributed systems and things like scalability, performance, and running production software. All that stuff became goals and it’s massive near areas of just learning that had to happen. Things had to be done completely different.

A great example is going back to episode one of Mobycast, talking about Docker, and how it’s one of those things that’s really different for folks. When they first adopted, they had to go through this learning period, things that they didn’t know before, things like networking and storage and what not. Maybe they didn’t think about it, they now did have to. Just by doing things like that, of setting charts for the organization site up, we’re going to use containerization. Just by that, you now have to have a bunch of learning going on.

Jon: Great stuff. Does that answer your question, Rich?

Rich: Yeah. I’m actually thinking about that quite a bit. It was completely independent of this podcast but I’ve always thought that when entrepreneurs or the owner of a company says I needed to clone myself, I’ve always thought what that person really mean is they need to clone their personal values and find people who have those personal values. I think that when you have a team full of lifelong learners, it facilitates itself. It’s really hard to find out whether or not you have those people on your team until they’re on your team.

I’m thinking in addition to pushing them over the edge or as a result of pushing them over the edge, you also have to have this mentality of, “It’s okay to break things,” at least once. Don’t break the same thing twice, but you need to be able to allow that. That’s hard for businesses. You have someone who’s really trying to push him or herself, things are going to break as a result. There need to be some sort of a balance there between how you can give them the autonomy to do that but at the same time, not let them go too far that they really need more senior people to pick up the pieces.

Jon: Yeah. For some reason, when you were talking and saying all that, I just kept thinking of Elon Musk. I think that he’s a little bit that way. He just throws people right over the edge and sometimes things break. There’s many things about Elon Musk but I think that’s one of the best things.

Okay, I think we should probably wrap up. It’s been about half an hour that we’ve been talking and this is the kind of topic that we could be still having drinks and talking at five o’clock this evening about, so let’s leave it, let’s let people finish their commute, and we’ll talk again next week. Thanks, Rich. Thanks, Chris.

Rich: Later.

Well dear listener, you made it to the end. We appreciate your time and invite you to continue the conversation with us online. This episode, along with show notes and other valuable resources is available at mobycast.fm/51. If you have any questions or additional insights, we encourage you to leave us a comment there. Thank you and we’ll see you again next week.