35. A Mobycast Retrospective

Rich: In episode 35 of Mobycast, we’ll talk about the original goals for this podcast and where we plan to take it in the future. Welcome of Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. Let’s jump right in.

Jon: Well hello there, Chris and Rich. Welcome.

Rich: Hey

Chris: Hi guys.

Jon: Good to talk to you today. Rich, what have you been up to this week?

Rich: This week has been a lot if just getting things squared away for the end of the year. We’ve got a bunch of projects that need to be finished before the holidays. It feels like a grind right now just getting things done but pretty good. Been bounced back and forth between different job roles so this last week has been mostly running code.

Jon: Right on. That’s pretty good. How about you, Chris?

Chris: I just got back for some travel, going out to sunny San Diego to meet with a customer. Had a really fun, collaborative working session there and now I’ve just been trying not to get overwhelmed by the AWS re:Invent session catalogue, trying to pick up my schedule for re:Invent which is now less than a month away. Over 2000 items in their session catalogue that’s spread over five days. It’s tough.

Jon: I was resigned not to go to re:Invent just because I figured there’s a chance that Kelsus could learn something or my presence there can help us learn something that might lead to more business but maybe not and it’s a pretty expensive gamble. re:Invent is not a cheap little week but some meetings came up that are pretty enticing, so just for that I pulled the trigger and decided I’m going. I’m really excited about that.

San Diego is Kelsus’ third hub. We go there a lot and actually we hired somebody there in San Diego. He’s on the website now, VJ, and it’s just great to continue to have a presence in one of our favorite places.

This week, I thought we do something a little different, Chris and Rich. I thought instead of grilling Chris and just wringing every last bit of technical information we can out of him that we take a look at where we’ve been and talk about where we’re planning to go with Mobycast. We’re not planning on slowing down or stopping anytime soon but I do think that we found our stride and we know what we’re doing a little bit better than we did in the first few episodes. We just wanted to tell you what we’ve learned and what we plan to do.

I guess we can get started. Maybe Chris if you would just take us out on a little journey. Tell us some of the topics that we’ve covered then and the themes that have emerged.

Chris: Yeah, it feels quite a laundry list so far. I think we’re up knocking on the door with 40 episodes of Mobycast now. We’ve covered a broad range of topics for sure. This all started with you and Rich and I had lunch there in Denver, Colorado, kind of throwing around ideas. We had a really interesting discussion about what’s the difference between virtual machines and containers.

From that the idea was sparked, like, “Hey, this is really interesting and this is probably going to be interesting to a lot of other people, hopefully. Why not have this kind of format or a podcast? There is plenty of material here to talk about that is interesting and it’s a challenging environment, the pace of innovation is increasing, and folks just need to know this, to build modern apps in the cloud.”

Starting with that very first one was like, “Hey, what is the difference between a virtual machine and a container? What is a virtual machine? What is a container?” Just branching off from that, I know we’ve done a lot of talks about just containers. What are containers? How do you build apps in a container? How do you containerize them? What are some of the best practices there? How do you deploy those? What’s the life cycle look like especially in the context of a CICD system? We’ve talked about security issues specific to containers and what creates a problem that’ fixed by them but then also some of the ones that are introduced by them.

Jon: And Chris, one of the things that I wanted to interject to you is that I think something that’s different about this podcast than a lot is that it’s just you and I talking to each other about this stuff. I think there’s sort of an assumption a lot of times when people start a podcast, “Oh, I’ve got to interview people, I’ve got to interview technologists, I’ve got to interview entrepreneurs or something, and that’s not the way that we decided to do it.

It’s been interesting because we actually have to make sure we’re ready to talk about things and that we are up to speed on the topics that we’re going to cover. It causes us to do a little preparation that way but it also lets us go deep and discuss things that you don’t get to see with one conversation with a new person every week.

Chris: Absolutely. It’s almost kind of like this concept just like far-side jobs. Just really what’s relevant in our world of have to build software, what we’re doing and what’s important, the challenge that we face, and just the techniques, best practices, tools, and things that we find useful.

Jon: Some other topics that we covered over the history have been lots of stuff related to AWS, which we just keep coming back and back to AWS, and then a few other things like real-life troubleshoot situations, we’ve done that a couple of times. I think I’ve really enjoyed doing is rehashing of conference talks that we’ve been to. I think a lot of times those talks are almost presented, especially with certain speakers, I wouldn’t say this is across the board but certain speakers like to make sure that the audience realizes how capable and intelligent they are by not lowering their discourse to lower to mid-level technologists and keeping it super super high levels, super difficult to understand for people. While that does achieve that, it doesn’t necessarily help everybody learn, so we get on to those talks, break them down, and help people that might not be able to digest it in the conference setting, digest it, so I really like those.

Chris: Those have been super fun because that’s a big part of it of just making it more digestible but then also I like the sidebar commentary.

Jon: The Mystery Science Theater 3000 of the conference.

Chris: Yeah, that’s it. The supplemental material that really you can apply a lot more context to it. We are more fortunate where we have a bit more time where we can spread it out over multiple episodes, go deeper on some of these things, and say, “How does this really apply to us in the real world?” That’s been a lot of fun.

Jon: Yup. Looking at that history and looking at the wonderful world of modern software make it so we can actually see the metrics and analytics, and what we found is that you, dear listeners, seem to have appreciate things that are kind of foundational, a lot of how-to stuff, a lot of ‘this is what this is’ type of stuff.

What you don’t seem to like is going deep on security or going deep on esoteric things that are not everyday stuff, for example, deep down secrets of Docker. It’s not as interesting for you as what’s some how-to for managing your Docker files. That’s more interesting stuff. Or what are the AWS services that we use and love at Kelsus. That seems to be the type of content that’s interesting. Good you learn that. Good to just get some history with the podcast and see what people like.

Based on that, I think now is the time to say how that applies to our own lives and our own world as people that manages software shop? We build custom software for clients. We have around 25-30 developers, I guess? It’s really closer to 30, although some of them are contractual right now. Chris, how does all this relate to what we do every day?

Chris: The job of a developer today, building modern software in the cloud that is production-worthy, where you have businesses that are relying on that software to operate correctly, efficiently, consistently, there’s a broad range of skills, techniques, and technologies that have to be employed. It’s turned out that there’s no real realization that almost all of these topics that we’ve talked about on Mobycast is kind of Engineering 101 for our development team. It’s all very, very applicable to building software in the cloud, building software that’s robust, building it in a natural way.

Jon: Let’s say it’s Engineering 1001. It’s going to be a graduate-level course.

Chris: It is. In a sense, it’s kind of like table stakes but it’s definitely not easy. I don’t know. I think we’ve talked about this before like Chemistry 101 in college, that is a foundational class. It’s big. I don’t know about you but my class had about 700 students in it, and I remember like the average exams score was something like 23 out of 100. If you’ve got a 55 on that exam, it was like an A+. It was introductory but it wasn’t easy and I think this definitely applies for what a modern-day developer has to deal with when building robust software in the cloud and dealing with all these technologies. Everything is changing so rapidly.

Definitely, it’s a big job with lots of stuff to learn that’s why it’s been fun doing these podcasts and talking through all these issues. Like when –  pointing back at our team to say, “Oh, you have a question to that. How to do logging for your back-end service?” “There’s a couple of episodes here that you should listen to because it’s really applicable.

Rich: Hey, this is Rich. Please pardon this quick interruption. We recently passed an internal milestone of 10,000 listens and I want to take a moment to thank you for the support. I was also hoping to encourage you to head on over to iTunes and leave us a review or a rating. Positive feedback and constructive criticism are both incredibly important to us. So, give us an idea of how we are doing and we’ll promise to keep publishing new episodes every week.

Jon: Right and we find that people that we hire –  because we do tend to hire a lot of people that are new in their career. Maybe they’ve only had 2-3 years of experience and we find that a lot of the people we’ve talked to haven’t run right up against that metal, running software in real production environments with real users. Not just 10 users but tens of thousands of users or hundreds of thousands of users. Since it’s a different game of availability and security, those things matter. They don’t matter as much when it’s more prototype-y or just a little startup that’s trying to see if people like something. Those things matter less in that situation no matter way more when a business depends on the software functioning.

We just find that when we hire, it’s whatever people have at. It’s become our job to give them that and doing our job, while fun, it’s also daunting. There’s a lot to learn. I realized in my own career, too, when I graduated in college and did my first couple of years as a software developer. I, too, had no idea about any of this stuff. If you would have said, go build the service and make sure that it’s secure and always available, I would have had no idea what to do. I guess Google did exist but I wouldn’t have known what to even google. We say that on our product and training website, you can’t google your way to Docker nirvana and I think really, more than that, you can’t google your way to becoming an expert software developer either, software engineer as it were.

I just want to say that that problem deserves attention. I don’t think that there’s a straightforward way to deal with it. It’s like this ad hoc mishmash, people become talented software engineers just by being around other talented software engineers. There’s no apprenticeship, there’s no place to go where you can make sure you do all the right things and check all the boxes and get there. Different companies have different definitions of it.

Chris, would you say, “I find that sometimes, people that I’ve been from startup to startup, really know their stuff and sometimes, people that have been at big companies really don’t know their stuff, and vice-versa, when people that have been from startup to startup never got a chance to really run software with a lot of users, and people that were big companies never got a chance to touch the high volume stuff,” have you seen the same?

Chris: There’s no standards, there’s not set of rules that people are applying to this. I think, plain out there is no such thing as an apprenticeship-type idea in the industry that is spot on. For the most part, how someone learns in this industry is really dependent upon themselves, how motivated they are to go and just learn on their own, if their product, their environment that they’re in, and they’re going to learn what that environment teaches them. If they have a strong team doing the right things, they’ll almost surely pick that stuff up and vice-versa. If they are not strong, then that’s not going to happen.

I think there is some merit into treating it more towards an apprenticeship, especially for teams and organizations that think about like, “What are the key principles that are important to us? What makes a developer we want on our team, what are core values, beliefs, principles, best practices? How do we qualify that and really mentor people to embody that, put them on a path where they’re going to become part of that entire culture and process?”

Jon: And then, “How do we measure them when we get there or when a person gets there?” That’s another thing. I remember having a conversation with my musician friend and he was looking for somebody else to join a band that he’s putting together. He lost a bassist, a drummer, or something. I was like, “How do you do that? How do you know when you found the right person?” The way he described it to me is that, “You just know when somebody has ‘it,’” and there was it with a capital “T”, and I was like, “Huh.” I guess if you’ve come to a certain point in your musical career where you have ‘it,’ you could probably recognize other people that have ‘it.’ I swear it feels like a little bit the same in software. I can tell Chris has ‘it’ and when I talk to other people that are kind of mature in modern software developers, I can tell when they have ‘it.’ Turning it from this mysterious ‘it’ into something that we can talk about with clarity would be so nice.

Chris: Yeah, absolutely. It’s very ad hoc right now in the industry. It’s always been. A big part of it is just 10,000 hours that comes up. But it’s not just 10,000 hours.

Jon: No, definitely not people have 10,000 hours that do not have ‘it.’

Chris: Yeah. It’s 10,000 of the right hours. It’s definitely a multi channel approach. You do need that environment and being on that right team that is embracing those best practices, that spirit of constantly learning, and staying abreast of just what’s happening in the industry. It’s very much a tendency for a lot of teams and people just in general to stick with what works. You can do that for a year or two, maybe, but after that it’s like, “Warning, warning, warning.” You really run the risk of all of a sudden you lift up your head and you’re like, “Wait, what happened? We were using cars yesterday and now it runs on a plane.”

Jon: And a case in point, just yesterday and today I was starting to feel this little feeling that some of our opinions about an episode we did about serverless, I started to feel a little dated to me. I feel I need, and I’ll probably do this at re:Invent—to reevaluate some of those opinions and think about it a little bit more because the serverless train doesn’t seems to be wanting to let off.

Chris: I feel the problem with the 10,000 hours is that you need to re-establish a new 10,000 hours regularly because of things like serverless. Just everything changing so quickly, maybe that’s the problem that you face when you’re in this industry is that, you can become an expert in something that no one wants to use anymore, and then what?

Jon: And that’s exactly what Chris is getting at a little bit is the right 10,000 hours, because within that right 10,000 hours is obtaining a mindset. Mindset is so key. If your 10,000 hours are spent correctly, then at some point in that time you’ll be working on your mindset and won’t be working on getting that mindset to a place where you understand the fundamentals and the fundamentals don’t really change all that much. A lot of the stuff we talked about in Mobycast is stuff that we did 15 years ago, too, just with different tools and techniques, and it was a little bit more difficult or a little bit less difficult, depending on the ebb and flow of software development. But once you’ve got those fundamentals and that right mindset, then you’re ripe for all these, facing your antenna towards the source of new and good information, your mental antenna as it were.

Chris: As long as you spry still.

Jon: Yes.

Chris: Because the problem is, the older you get, the less likely you want to change the way you think about things, even if it’s practically.

Jon: It is a state of mind as I get older.

Chris: Yes. I tell that to myself at times.

Jon: I think that’s where we’re going with this. I don’t know, Chris, if you want to say anything more concrete about where you think we’re going with Mobycast.

Chris: I think it’s just to realize it’s definitely much broader conversation than just something about Docker or even just containers.

Jon: Or AWS or any one topic.

Chris: You can’t just build today as a software developer building software for the cloud. it’s complicated and you can’t talk about this one thing without bringing in other topic as well. So definitely realize the scope, the breadth of topics that we’ve talked about in this is much larger than Docker and containers.

That feels okay, though, right? That’s natural. It’s just the scope has broaden, there’s plenty of content, it’s interesting, it’s useful, and we’ll continue going there.

Jon: Yeah, we’ll continue going there and I hope to augment our conversations with other stuff over the course of the next who knows how long, but this whole problem of training developers is weighing heavily on our minds, so we’re going to work on it.

Right. Thank you. Thanks, Rich. Thanks, Chris.

Chris: Thanks guys.

Rich: See you guys next week.

Chris: Bye.

Rich: Bye.

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