cover of episode Behind the Mic: Adam Gordon Bell on Communication with Software Misadventures Podcast

Behind the Mic: Adam Gordon Bell on Communication with Software Misadventures Podcast

2024/8/6
logo of podcast CoRecursive: Coding Stories

CoRecursive: Coding Stories

AI Deep Dive AI Insights AI Chapters Transcript
People
A
Adam Gordon-Bell
G
Guang
R
Ronak
Topics
Adam Gordon-Bell: 他最初的目标是成为一名优秀的软件工程师,但他逐渐意识到沟通能力的重要性。他发现那些他所敬佩的工程师之所以成功,是因为他们能够有效地沟通,将复杂的技术问题解释清楚。他认为有效的沟通能够让想法在人们心中清晰地展现,这非常有价值。他从后端软件开发转向播客,再到开发者关系,正是因为他对沟通能力的重视。他分享了他从在Peterborough的Opertel工作到远程工作的经历,以及他在这些经历中对沟通重要性的认识。他还谈到了他作为工程经理的经验,以及他如何认识到团队效率问题并非源于技术技能的不足,而是沟通的缺失。 Ronak: 他表达了对Adam的职业发展历程以及对沟通能力的重视印象深刻。他提出了关于Adam在职业生涯中哪些时刻让他意识到沟通能力的重要性,以及Adam是如何将沟通能力从一种提升工作满意度的技能转变为一种战略性优势的问题。 Guang: 他关注Adam的播客风格转变,以及Adam在播客制作过程中遇到的挑战和经验。他提出了关于Adam是如何开始从事播客工作的,为什么决定创建自己的播客Codecursive,以及在播客初期遇到的最大挑战的问题。他还对Adam播客中引人入胜的故事讲述方式印象深刻,并对Adam的播客风格从技术性转变为故事性驱动,以及Adam的播客制作流程进行了深入的探讨。

Deep Dive

Key Insights

Why did Adam Gordon-Bell shift his career focus from being a software developer to communication and developer relations?

Adam realized that the people he admired, like Joel Spolsky, were not just great engineers but also great communicators. He understood that their impact came from their ability to explain and share knowledge, which led him to value communication more than just technical expertise. This realization shifted his career towards developer relations, where he could combine his technical skills with storytelling and communication.

What was Adam's first realization about the importance of communication in his career?

Adam's first inkling about the importance of communication came when he transitioned to a remote job and missed the informal knowledge-sharing that happened in the cafeteria at his previous workplace, Opertel. He noticed that much of the problem-solving knowledge was transferred through casual conversations, which he no longer had access to in a remote setting.

How did Adam get started in podcasting?

Adam got into podcasting after reaching out to Jeff from Software Engineering Daily, who needed help with interviews. Jeff suggested Adam find people to interview and send him the recordings. This led Adam to start his own podcast, Code Recursive, after Jeff stopped accepting external interviews and Adam had already booked several guests.

What is Adam's approach to storytelling in his podcast?

Adam focuses on finding stories where the protagonist has an objective and faces obstacles. He leans into the actual experiences of his guests, rather than just technical explanations. He believes that storytelling is about making everyday experiences compelling and relatable, even if they are not extraordinary.

What challenges did Adam face when starting his podcast?

The hardest part for Adam in the early days of starting his podcast was reaching out to potential guests and dealing with the fear of rejection. He also struggled with the editing process, which he found time-consuming but eventually embraced as a creative part of producing the podcast.

How does Adam prepare for podcast interviews?

Adam conducts pre-interviews with potential guests to understand their stories and ensure they are a good fit for the podcast. He uses a checklist to guide the conversation and focuses on finding moments where the guest had an objective and faced obstacles. He also allows the direction of the interview to change if something more interesting comes up during the conversation.

What role does music play in Adam's podcast editing process?

Adam uses music to enhance the storytelling in his podcast. He learned from NPR-style classes to use music to create momentum and emphasize key moments in the episode. He enjoys the process of adding music, even though it can be time-consuming, as it adds an emotional layer to the storytelling.

What is Adam's current goal with his podcast?

Adam's current goal is to make everyday experiences interesting and compelling through storytelling. He wants to explore how people's daily struggles and small victories can be turned into engaging stories that others can learn from, even if they are not extraordinary or dramatic.

How did Adam transition into developer relations?

Adam transitioned into developer relations after someone reached out to him about a role that involved communicating with developers. He initially struggled to find success but learned from Mitch Weiner, a founder of DigitalOcean, that the key was to understand developers' problems and provide solutions. This approach helped him grow in the role and focus on educating developers rather than just promoting products.

What does Adam believe is the most important skill in developer relations?

Adam believes that understanding developers' problems and providing solutions is the most important skill in developer relations. He emphasizes the importance of writing tutorials and educational content that helps developers solve their issues, rather than just promoting products. This approach builds trust and awareness of the product organically.

Chapters
Adam Gordon-Bell initially aspired to be the best engineer, but realized that the engineers he admired were excellent communicators. He learned that effective communication is crucial for conveying technical knowledge and making a significant impact.
  • The best engineers are often excellent communicators.
  • Effective communication crystallizes complex ideas.
  • Communication is more important than simply technical skills.

Shownotes Transcript

Translations:
中文

Hello, this is Code Recursive and I'm Adam Gordon-Bell. Today the tables have turned and you're going to hear someone interview me. Ronak and Guang from the Software Misadventures podcast are going to interview me about my history as a software developer and I guess this big idea that I don't think I've shared too much about the importance of communication. I don't know why I wanted to be best engineer, but like there's all these people

that I looked up to in that time. Like Joel Polsky, like I want to be that great. But like, if you think about it, the reason we know about them is because actually they're communicators, right? They're explaining problems to us. Like I thought,

This guy has a blog because he's the most amazing engineer. But no, he, I know about the things that he's done because he talks about, right? Like all these people I looked up to, what they're actually good at was communicating, right? The person who wrote the book that I wanted to ask questions about how to do

functional programming. Like it's not clear they were the best functional programmer in the world. Hopefully they were decent at it. But no, they had written a book, right? They had spent a lot of time communicating. So I think that actually I maybe realized that my goal was misplaced, that there was a larger goal or something that...

Yeah, I wasn't seeing that all these people who communicate are the people that I look up to. Right. And it can be super impactful if you can take something and explain it in a way that lets it crystallize in people's minds. And I don't know that I'm the best at it, but it feels very valuable and important.

So that's going to be this month's episode straight from the feed of the Software Misadventures podcast. I myself have been caught up in job hunting, as I mentioned last time, going through the various interview stages. Take home assignments have been a lot of fun. Coding interviews. I used to be good at those. Super not good at them right now. So that's an issue. But yeah, I've had a couple job places that I thought were really promising that didn't work out and a couple more, you

you know, that I'm still working through that I am excited about. So hopefully new developer relations engineer type role coming soon. But until then, right?

As I'm busy practicing leet code problems and trying to do well at job interviews and find something that works for me. But while I'm getting that all together, I thought you might all enjoy hearing more about the backstory of me and of the podcast. Because I think that Ronak Ngong did a great job of pulling a story out of me about my journey, right? From being a backend software developer to...

doing this podcast and then learning really about the power of communication and believing in that so much that I shifted my career to go into developer relations where kind of do this as a job. And it's a weird job, but super powerful one. And hopefully this interview will help others understand that.

Welcome to the Software Misadventures Podcast. We are your hosts, Ronak and Gwan. As engineers, we are interested in not just the technologies, but the people and the stories behind them. So on this show, we try to scratch our own edge by sitting down with engineers, founders, and investors to chat about their path, lessons they have learned, and of course, the misadventures along the way.

Awesome to have you here, Adam. You're the host of a co-recursive podcast. Before our conversation, you were telling us a little bit about your background. I love sort of the arc that you gave, the focus being the value of communication and then how you were able to get there

the different steps in your career. So I thought maybe like interesting place to start is going back to when you were first getting started as an engineer. Like, was there different points where you specifically recognize these like, oh, wow, communication is something that's quite powerful, but that's very under leveraged by like your peers. So I used to work at this place here in Peterborough called

And Opratel made a lot of friends there. And I think like, I just really wanted to be really good coder, I guess, you know, and they had like a large complicated code base. People were always adding, it was like enterprise software, people are adding features as fast as they could, and like, nobody can keep track of any of it. And like, I just wanted to get really good at it.

at that, right? Like, oh, you want to be the guy that they go to when something's on fire because you know all the stuff, right? And there was people who knew all the stuff and I'm like, I want to be one of those people. So that was very important to me.

I don't think I thought communication was important. I just wanted to have this great skill set, right? And develop it. Yeah. And then I ended up transitioning from there to working someplace remote. So it was actually a weird thing where my boss had left and I liked him and he was interviewing for this other role, but it was in another city. And he's like, yeah, you could do it remote, like from home. And I was like, that sounds awesome. It turned out the company was like less successful

on point with me being remote than he was, but I did end up taking it even though it was like iffy, whether I would have to move Kitchener, for instance. But I liked working from home, but I missed some of the stuff from Opertel, you know? And like, it wasn't, you said communication, that's like a big word. It makes me think of like writing up documentation for something, right? But like what I missed was like being in the cafeteria, like we had this cafeteria

And, you know, you're like having lunch or waiting for the free microwave or whatever. And, you know, somebody's telling some story about the something server was down last night and like, and I got called in and then somebody's like, oh, did you, did you check? Was it the, you know, was the disc full? And they're like, oh, I thought it was the disc full, but it wasn't the disc full. And like, oh, was it the whatever? This was a...

Windows server. So it was like, was IIS like leaking memory or something? And anyways, people like go back and forth through it and it's like a fun game and you're like trying to figure out. And the guy's like, no, no, it turned out it wasn't at all. Like somebody had pointed something to the wrong server and blah, blah, blah. There was always these stories, probably because people were moving too fast and things were always blowing up. But like a lot of the knowledge about how to solve problems, about how things worked there, right?

It was actually transferred just in people shooting the breeze in this cafeteria setting. And I didn't get that once I started working remote. So that was my first inkling, I think, that like, oh, this is something important. Nobody says like, oh...

You know, we would like to give you a raise because people have learned a lot from those crazy stories you tell at lunch. But like, it turns out that that's very important. And it's like a thing where people get a lot, like people talk about mentoring, like a lot of it is right there in these like casual venues. So that was my first inkling that like, this is something important. Interesting.

And fast forward a little bit. So you mentioned that you then got into management and then later on DevRel. Like, how did that sort of experience like evolve into something where you're like, okay, there's a strategic point to it rather than just something that's very, makes the job more fulfilling? There's like 30 steps, but like, I guess that's the problem. But like, yeah, so I started working remotely. I worked on this team.

really smart people, some of the smartest people I worked with before. And we weren't always actually accomplishing as much as, as I thought we should. It's like, you know, sometimes you wish you're like, man, wouldn't it be great if the whole team was rock stars? Like you imagine there's these 10 X developers out there and they'd be so amazing. Or maybe you just imagine like you didn't have that guy who you keep having to walk them through things. Yeah.

That was me. That was me. That's why I raised that guy sometimes. But like the team was very skilled, but we weren't getting as much done as I thought. Like it just didn't seem to be working. And so that was my entry point to becoming an engineering manager. Cause I thought like the problem here isn't technical skills. Like all of the people on this team are super talented. So something else is the problem. Right. So that transitioned me to being an engineering manager. And then

Eight more steps and then I end up in developer relations.

So I wanted to fast forward a little bit and talk a little bit more about podcasting. So before, I think you started Codecursive, you were a podcast host at SE Radio, software engineering radio for folks who might not know. I think IEEE actually managed this podcast. But can you share a little more about how you got into podcasting in the first place? There was this podcast called Software Engineering Daily. And Jeff, who was the host, he...

made an episode for a long time every weekday. And that was a lot. So anyways, I was listening to one of his episodes and he said, I need some people to help me do this. Right. So I reached out to him and he said, yeah, like just find somebody and interview them.

and like send me the wave file or whatever. Like there was very little tutelage involved. So no waiting almost. So that was my entry point. And then like he, after a while, I think he took on a couple of people like this and he was like, this is unwieldy. I'm going to stop doing it. But then he recommended me to the software engineering radio and they, yeah, they're based on the IEEE. He had started there. They had more structure.

And that's how I got into it. But I mean, the motivation was like I was still in that world where I was like, I just want to be the best programmer. Like I want to know everything and be able to tackle all these problems. And I was at this point, like I was a Scala developer and I was getting deep into like functional programming. And there's like a million things to learn. And it's like it's just it seems like vast.

And so it was like an opportunity for me to just like talk to these experts and ask them questions. It was like, I have a question about this thing. This guy wrote this book. Like I can just talk to him and ask him questions. Yeah. So like at some point you decided to start Codecursive. What made you make that jump? Because SE Radio was kind of doing a lot of the hard work that goes into podcasting and has a good name behind it. Then why start? Yeah.

I was doing these episodes for Jeff, so the Software Engineering Daily, and I was reaching out to people to interview them. And I didn't really run it by him. I just started booking more interviews and some of them I booked far out. And then one time I sent him a thing, like an episode I recorded, and he's like, okay, well, we stopped doing that. Like, right. And I still had more interviews booked. It was like, I guess I'm starting my own podcast. Like I already have interviews. And I remember the first interview that I did where I was like, okay,

So I said, I was interviewing for this podcast. Like, actually you're being interviewed for as yet unnamed podcast that I just made up. Yeah. People didn't seem to care. And I remember talking to Jeff when I told him I was doing this, I was like, okay, well, like I booked these couple of first episodes of my podcast saying it was yours because I mean, accidentally, like, how do I book for other people? And he was like,

People like to talk about themselves. I wouldn't worry about it. Like, he's just like, just email people. Right? I'm sure you guys have noticed. Like, it's actually not that hard. I've been surprised by just how kind, I guess, like, fancy or like famous people are about their time. Because I think that's the thing I worry about the most, right? It's like they have this busy schedule, you know, all these things. Talking to some random dudes from the internet seems to be low on the priority list. But...

I think, yeah, if you're pretty clear about the messaging to show that you've done your homework, that definitely helps. I'm curious, like in those first days, what were

For us, I think it was the writing the emails. I think that was the most painful to actually do. So it's kind of funny to hear that for you. It's like you already probably have a process at that point, right? If you already booked, you know, quite a few. What was the hardest part about the early days of starting the podcast? That's a good question. Definitely reaching out to people feels fraught, right? Like you feel like you're putting yourself out there.

And I was looking at your episodes. Like, I know that there's people in that list that I have reached out to in the early days who said no, right? And maybe they would say yes now, but I'm never going to reach back out to them. It's like you feel.

You feel rejected. It's not like rejection. I'm sensitive to, right? Like probably somebody is just like, no, I'm busy. I can't do this. Right. But my perception is like, oh yeah, they, they look deep into my soul and said that I'm not worthy. Right. It's like, that's, that's so real. And it's super funny because

Roddick and I actually, we had an incident where someone that we reached out to like maybe two years ago and then they said, no, now is not the good time. But then they actually came on the show because I didn't realize he wrote the email like two years ago. So then I was just like, oh, this person seems pretty cool. Like, let me just write the email. So that was a pretty funny moment. I remember as charity majors, I...

I was trying to figure out reaching out to people. And so I read some articles about it by some marketers or whatever. I don't know. Like, don't look for advice on like how to cold outreach to people. Like it's really, yeah. Oh no, it's terrible. Like do almost nothing that people say on the internet. So somebody recommended like, oh, there's these things and they'll like, basically like set up a chain of emails where you reach out to them and then you follow up and then you follow up. Right. And so I found some tool that's

It's like, so I wrote the email to charity and then like three days later it would send a follow-up shed and responded. And there's like three of those. And so I emailed her, like I set up the thing and I sent it to her and she emailed me like back like 60 seconds later. And she's like, yeah, sure. But like, what's going on with all these emails? And they had all sent at once. So I'd sent it. Yeah.

I really want you on the podcast. Would you like to be on the podcast? And then like, oh, you haven't come back to me. No, you still haven't come back to me. Yeah. That's how fast I iterate. Within 60 seconds. So maybe that's the method.

So one question on the follow-up, this is something that I struggle with a lot when it comes to writing an email to reach out to a guest. One part is you want to do some research to write a thoughtful email instead of a random cold email, which I think is okay. Like there's a way to do that. But then in the follow-up, at least I...

feel a lot of friction in doing that follow-up. And I have Guang here pinging me almost every three days. Did you follow up yet? And I don't have one of the tools that you mentioned. And when I say there is friction, for me, that friction comes from not knowing exactly the language to use to follow up. There are certain templates that I use, but then

for whatever reason, I get bored and I don't like them anymore. And then I'll go to chat GPT and waste 15 minutes just to craft like one line follow-up. I'm curious, is there language that you figured out that you used in follow-up emails that just makes it much easier to do that? No, I guess the answer is no. It's funny because Guang, you had to follow up with me for this just because I don't know, there's a lot of emails and I forgot. I was like, I'm going to respond to that and then I didn't. And then...

Yeah. I did like a little retrospective on like just like the power of like following up. I think I really learned it when I was doing like the third Insight Bootcamp to like to try to do like a VC funded company. One of the advisors, so Yuri, who used to work at YC, he was like, yeah, you got to set it up, you know, six follow ups. I was like six? Like, are you kidding me? Like, I would like, I would definitely report spam. Like, so then I think we kind of settled like

Like who on earth? Anyways, but then that was also kind of drilled into my head. But then he was until much later when like, I think I saw Jake doing this. So he's the founder of Insight. And then he just wrote like very casually say kind of like, hey, just quick reaping, you know, in case that email got buried.

And then he says, but if not, it's not the best time. Like, no worries. Like that line to me was like magic because he just like absolved me from all the, cause I felt so bad for like, I feel like I'm really begging for like, oh, can you please like, you know, do this thing? Can you please like take a look? And then that really changed the equation to more like, hey, I'm trying to find like a match, right? To see if there's like value that we can provide. And if that's something that you're interested. So it's kind of like, okay, it's more like equal.

equal instead of like I'm trying to you know get stuff from you so yeah now I'm much less scared about doing follow ups yeah I have this thing okay one second followupthen.com all it is followupthen.com all it is is like a whole bunch of email accounts that you add to your contact list

And so when I message somebody, I'll just write them a message and then I'll BCC like two weeks at followupthen.com. And it just emails me the email back two weeks later. So it's like,

That's my system now. I don't have any. So you don't, you keep track of it. That way you can do the follow-up or if you can check to see if you still want to follow up. It just puts it back to the top of my email box. And then I'm like, okay. Yeah. Like, and I agree, like saying like, yeah, no worries if it's not a fit or whatever makes it feel, I don't know, less on the line, I guess. Right. Like, yeah.

So I was reviewing Cora Kersive's profile on Apple Podcasts, and there are a bunch of good reviews about your storytelling, where people like every story feels very unique. It's very engaging and things like that, which is pretty amazing. So I'm curious, like, how did you figure out what sort of storytelling mechanism you want to use in the podcast? And how do you now go about structuring the episode?

This is mostly me trying to learn. So software engineering radio is very technical and like dry, I would say. And they have like a very strong format. It's like, let's interview somebody about the cap theorem. Right. And then it's like, you have to have like an outline prepared and you have to show that this person's an expert. And then you can go through like, oh, what are the trade-offs of this versus that? And it's very dry. You can learn a lot, I guess. But I

As I, like, as I was doing it and then kind of repeating it on my own, talking to people for a co-recursive, like I found like the parts that spoke to me were not that right. Like the parts that stood out to me talking to people was when people shared things, right. We go back to what I was saying at the cafeteria at Obertel and, you know, they're explaining like, oh, the server was down and how do we look into it?

And like that stuff was so much more compelling to me. And I just wanted to do more of that. The last interview I did for Software Engine Radio was Stephen Wolfram. I was talking to him about his, you know, his programming language and all the things he's built. But then I forget what we started talking about. Like if he could estimate...

you know, something to do with like how much he weighed based on his calories or something. And he's like, you know, coding and his language and trying to figure out how much he weighs. And it was just like us having fun, like using his Wolfram Mathematica and stuff. And, and,

I was like, this is better, right? It's like just an experience rather than him explaining the trade-offs of various things. They cut it from the episode. Like they got rid of it all. Oh, wow. And he was, I forget what we were coming up with, but it was like I was throwing problems at him and he was going to calculate them. And I was like, oh, I'm in Peterborough. And he's like, Peterborough, UK? I'm like, no, Peterborough, Canada. And he's like, Mathematica is like his baby. And it's like, he was like the...

Tom Cruise in Minority Report. Like he was like pulling the data from various places. And I was like, this is awesome. But yeah, they didn't feel that was like educational.

But the point is I was like, this is the good stuff, right? Just like lean into the actual experiences that people have. Yeah. So the, I don't know, I don't have a quick answer for like how you do that, but like pay attention to what you find interesting. Right. And like double down on that, I think is the key. That was, that must've been super, uh, interesting, weird experience, right? Being like, oh, I think I got this really golden nuggets, but having that cut out, like, do

Did you, how do you work with the editor like in that process? Like, do they kind of come up with like, hey, you know, the outline that you mentioned, it's like, we need to hit these things. And then do you get much say in terms of like, so at the software engineering radio, they, Robert who runs it, he has a very in-depth process. Like the manual that he made for it is online. And actually like, I don't think he's wrong about cutting it because the way that that podcast worked was always like,

about the technical details, right? It wasn't like, oh, let's have some fun with Stephen Wolfram, right? It was like, tell me about Mathematica and like, what's the history of it? And what, you know, how would you parse it and whatever the details are. But so their process was you'd come up with an outline in a Google doc, the editors and the other hosts would review it, offer feedback, and then you record the episode. And then you can provide a list of edits if you're like, oh,

you know, we need to cut out this one part, you would just give like timestamps. And then they kind of took it from there. And usually they just went with whatever you had. But my interview with Steven was long because we were just like messing around. And so I guess he wanted to cut some stuff out and he's like, yeah, let's get rid of this, like playing around. Like what's the fun of that?

Along those lines, so Ron, I mentioned this as well. So you started out co-recursive back in 2018, being pretty technical, like you said, coming off like Software Engineering Daily.

And now it's, you know, it's a very like storytelling driven, right? I think you mentioned that the raw interviews can be like up to two hours versus like the final product, right? It's like only maybe like 40, 50 minutes. So there's a ton of like editing, you know, you're thinking about the story. So it's super different now in that, like, were there any like pivotal moments in that journey in this like evolution of the podcast that you like that comes to mind? So, yes. Yeah.

But many. So the other day, I got all these emails from people who like want their CEO of almost always Bitcoin startups, but like varying things to like be a guest on the podcast, right?

Somebody reached out, wasn't like a blockchain thing, but they're like, oh, you should talk to this, to our CEO, whatever. It was like sort of interesting. You know, they're like, oh, Ron can talk about our new release and we have a new feature flag on the settings page. I was trying to explain to them, like, no, that's not what I need. Like,

Does he have an interesting story? And they're like, oh, he's got tons of stories, right? And so we had some back and forths, but there was like a gem of stuff where I was interested. And so we got on a Zoom call to talk it out, right? And I was telling this person, this is what I learned. And I tried to give it to them, right? So this is a story. I am here in Peterborough. A couple months ago, I'm driving to see my wife at her work. And I'm almost at her work.

and I'm at a stoplight and there's like several cars in front of me and I have to pick her up. Then

You know, the light turns green, the car in front of me goes, and then like this guy runs out in front of my car and he's on crutches. Right. And he doesn't look well, but not in like the injured way, but in the, like, I've been living a rough life type of way. And he's like screaming, right. Just like screaming, not at me, but like often some other direction. And then I see what he's screaming about. And there's another guy in a wheelchair screaming.

that he's screaming at and they're screaming back and forth. And the guy in the wheelchair, like, first of all, I just want to go. Like, I want to drive. I can see my wife's work because it's like on the corner. But like this guy is standing in front of me, like having the screen match. And in a way, I don't want to catch his attention. Right. But like, I also want to get by him. And then the guy in the wheelchair is like wheeling. Right. And he like builds up speed and he actually smashes into the guy on the crutches, knocks him down. The crutches are on the ground. Like, I'm still there. Like, I still am like, I'm going to be late.

to pick up Courtney, my wife. I'm probably not that late, but like, I don't want to anger her. Like I borrowed her car and blah, blah, blah. And then the, the guy with the crutches like gets up and I'm like, Oh good. He's going to get out of the way. But he takes his crutch like a baseball bat and he goes to the guy in the wheelchair and like smashes him. And they're just fighting like out in the middle of the street. Right. And, um, so I say to this lady, like,

That is a story, right? Like I, I'm the protagonist and I'm trying to get to my wife's work, right? That's my objective. And then there's obstacles, like the obstacle of these guys, like a guy in a wheelchair and a guy, they ended up being fine. Like they both, like the, I don't think the wheelchair guy was a paraplegic because he kind of jumped like, and they were wrestling. So like he obviously could use his feet, but yeah.

Yeah. But I was like, the new settings thing on, on the feature, whatever, it's not a story, right? I need like the, what, what did Ron do? Like, what were the things that happened? Yeah. So this, this is what I think about, right? It's like, you need a story and like a story is a very simple thing. It's that, right? You have a protagonist, he has an objective and then there's obstacles. And that's like, that's like 90% of the thing, right? It's just like,

You find somebody who has those ingredients. Sometimes you don't know, right? You just start talking to them and then they're like, they tell the story. But that's what I focus in on. Halfway through the story, I was like, where is Adam going with this? And then I realized, I realized, oh, this is an analogy that he's trying to draw for the code email. And then I realized, oh, wow, that's actually very spot on. And then I realized,

Well played, sir. Well played. How do you go about finding the right guests who have a good story to tell, by the way? Like that's hard because you don't know a lot of people and you don't know their stories. Agreed. Yeah. That's the hardest thing, right? Sometimes I'll see something and I'll be like, oh yeah, I've got to talk to this person. Sometimes I will just talk to somebody and like basically I'll do a pre-interview. I'll just chat with them and see, you know, what's going on. You know, tell me,

something interesting to happen to you, kind of explore it. But yeah, I mean, I think that's difficult. And the story doesn't have to be, like I did this episode with my friend Don and he had worked with me at this place, Albert Hall, I was describing with the cafeteria and the stories and whatever. And like the story was just about how, like he started at this place as soon as he finished university.

And, you know, he just felt like they never valued him. Like he stayed there for a long time. Like he never worked anywhere else. He never got the context for like, oh, maybe this isn't a great place to work. And like, I guess his story was like, you should value yourself because I went through this thing. Like I was working so hard for this place. And then I found out like I wasn't being paid well and there weren't good working conditions and whatever. So, I mean, there doesn't have to be a guy with a wheelchair and a guy with a crutch.

It's more like it's through the eyes of the person you're talking to, right? I guess is a way to think about it. You mentioned pre-interviews. Do you do that commonly? And if so, then what does your pitch look like to the person you're reaching out to? Yeah, I just email them and say, hey, I think you could be an interesting guest for my podcast. Do you want to have a chat about it? And then I send them a Calendly link.

And I think sometimes that it can be valuable for them too, because they get to ask me questions. I think they just get to meet me. Right. So it's not like a blind date. It's like, oh, we've, we've chatted before. Yeah. Yeah. Do many people take you up on that or is it only a handful? I always talk to everybody first before I interview them. Yeah. I didn't always, but yeah, it's super helpful. Hmm.

I took some classes from the Independent Association of Radio Journalists, I think it was called. Anyways, NPR type folk. And they were super valuable. But like one thing that proper journalists do is audition people. Like they'll audition people all the time.

And like, you know, something happens like, okay, the big security thing that just happened. What was the company again? CrowdStrike, right? So you're writing an article about CrowdStrike and like you need a quote from like an expert or whatever, right? Like a lot of times journalists will talk to you.

like seven experts, right? Like whoever they can get ahold of quickly. And they're just looking for whoever's the interesting person. And like, that will be the quote that they use, right? So basically they're auditioning people. Like who's going to say something that's, you know, poignant and gets my point across.

So yeah, for radio, they would call that like a pre-interview. If it's like a TV show, right? Like often they have producers who this is all they do is like try to reach out and find like, okay, we need somebody to fill in this little segment, right? Like, who do we got? And like, are they interesting? What are some traits you look out for during those interviews to like see if they're, what would you call them? You wouldn't really crazy. You wouldn't believe it story. Yeah. So yeah.

I think there's just two criteria. One is that they have, yeah, some sort of story where they have, they had an objective and like they're, they're willing to share that. So that's like, has a story. And the other one is like, is a talker to, to use just, that's my generic term for somebody who's just like interesting to hear talk. What questions do you ask to get these responses from them? Like,

Do you have a story? Is that the question? I'm assuming something else. So the talker thing, I think you'll know. Let's look. I have a checklist here. Please stand by. I'm a big fan of checklists. Yes. So when was a time when you thought things were really bad? Usually there's like something else attached to that, right? Like when...

in your experience at LinkedIn where you're like, oh, we're screwed now, you know? And we'll say like, oh, you know, yeah. And like, what was the scariest thing, et cetera, attach that to something, right? So it's like, yeah, tell me about your time about LinkedIn. Like, what was the scariest thing that happened when you were there? You know, what was the time where, you know, you really, those are the only two questions I have in front of me. But yeah, it's usually like,

And how long do you schedule these chats for? Like 20 minutes. And after the chat, have you said no to any guests? Yeah, I'm not good at saying no, though.

I would imagine that to be a hard part because you're reaching, you're inviting someone to say, hey, you could be a good fit, let's chat more. But then you may not like the stories or maybe they don't have as many as you might think. Yeah. Have you said, if you have said no, I would love to know how did you go about it? Yeah. I think I've just said to people, like, I'm not sure if it's like quite a fit or...

But yeah, I don't like to do that. But yeah, I mean, that's the thing that I think the journalists are good at that I'm not, right? It's like, they're like, oh, I'm going to talk to six people and only use one of them where I feel like,

I'm using people's time. So like there should be some end result. Yeah. In this case, like when you have this pre-chat with them and you invite them back on the podcast, what does your prep typically look like? And do they know that this is the story that you'll focus on? Yeah. I try to let them know, you know, what's interesting to me. And then sometimes though, during the interview, the directions change just because something more interesting comes up.

I interviewed before this guy who he created a Google AdWords, I think, or AdSense. We were going to talk about that. So I did the pre-interview. We chatted. It sounded pretty interesting. He was like a very early Google employee. But then when we were talking, I was like, well, you know, let's go back further. And like he had worked at the JPL, the Jet Propulsion Laboratory.

And he had been this person who had pushed for them to use Lisp and had gotten Lisp on this spacecraft and then had a problem with it and had to get a REPL going into this thing that was 100,000 miles away in space through satellites. And he's like, I don't know how Lisp REPL works, but he's printing out, I assume, 1,000 open braces from space. So I was like...

I just changed what we talked about, right? Like we didn't, I mean, we still talked about the AdSense thing, but I guess that's the benefit of being able to talk to somebody for two hours and then cut it down to an hour, right? Like once I had that, I was like, okay, maybe this is the story. That's really cool. So in other words, you talk to somebody, you look, you know, what's an interesting experience, but then when they tell, like, then you just pay attention to what's interesting and keep leaning in on it, right? Maybe once you edit it,

It changes as well, right? You're like, oh, the focus should really be X. Do you edit the podcast yourself or do you outsource that? Yeah, I edit it. It's a pain. I think it's super cool that you take so much effort into the editing process. And not because for us, it's more of a chore, but for you, right? It's like a creative process, right? Like that's where you have all the Lego pieces and then you're putting together something, you're creating something.

I'm curious, like, what's your favorite part of the process of making a podcast episode? Because for us, I feel like there's less choices versus for you. I feel like there's a lot more. You're doing a lot more interesting stuff. The problem is, like, I kept on putting more work into, like, polishing the episode. And so sometimes I feel like it takes me so much time that I'm like, oh, what am I doing? But yeah, like at some point somebody told me like, oh, you should have music.

And then, so I did put music in like just at the beginning. And then at the end, like, I think this person wanted me to like, like score it like Hans Zimmerman or something. I was like, yeah, I don't even know how that works, but, um, it turns out like, like putting the music in is super fun. So that was like just a fun part. I enjoy. Right. I, once again, I took a little class from some sort of like NPR folk.

And so instead of just having like, oh, we're going to play our theme song, right? They would, you know, try to have like a song, you know, like where the kind of like beat drops at the right time to like cut you into the story. And that is like putting that in. It's kind of a pain because I'm like, oh, I still got to do that. But it's super fun. But you mentioned a class before as well. Can you talk more about that class you took? Yeah, I took this class from Christina Shockley.

And I took two classes from her. I forget what they were called. But she works for NPR. Does one of their morning programs, I think. But just like the Michigan version of it, I believe. Anyway, she's super talented. Took this class. It was all like journalists and radio people in it, except for me, which like totally freaked me out. Like there's a guy from The Economist. And I was like, what am I doing here? Like I just interview people about like whatever. Wait, how did you...

How'd you get it? Like it's a, so there's this thing called air, like an association for independent radio journalists. So you just, you just pay to join like, and then they have classes. And then I paid for the class. One of the things she had us do in the class was every, so I think we had a class every Sunday for several hours and we did like various things, but she also had us make like a,

there was an assignment every week and it was like making a two to five minute like audio, which, you know, like if you're listening to the radio, sometimes they'll like cut into like, oh, here's a whatever small story about a man in Newfoundland who's reunited with his dog or whatever. It's like a little thing, but she had the, she had us make them like about ourselves and like reflecting on ourselves. Right. So it was like a audio piece. Like it's almost like an audio essay, I guess about yourself, but like making it very small.

and, uh, condensed and then she was giving feedback on it. And, uh, yeah, so I don't know, I forget how long the class went, but it was like making these every week and it was pretty fun. It's like writing like a, you know, a reflective little essay, but instead of for your blog, it's like your, your speaking. Um, so I learned a lot from that process that like, you can make something interesting in audio by just like reflecting on, on

something that's going on in your life. I'm very curious about like the, the, the conviction aspect of like getting enough, like conviction that like, Hey, this is something I want to really get good at. Right. Like I want to invest in learning all these new skills, right. Skills that are core to like producing like this, uh, great piece. Um,

But before that, I'm curious about like, were there any engineering practices that you thought that were pretty helpful in kind of systematizing this? Yeah. I have checklists for the process of going through an event. So we've kind of built them up over time. And then I tried to write down things that don't go well. And I keep a list of that. And so it's just like some process was a pain or I forgot to do this thing. And then...

I try to go back and try to knock some of the, so that's like my, I guess like refinement step, right? And so if I write them down a couple of times on this list, like, oh, this didn't go well, this didn't go well, then, you know, I can go back. Because oftentimes it's like, okay, yeah, it was a pain to do this, but like, I got to get the episode out. Like, I don't care that it's a pain, I need to do it. But then afterwards I'll have it on the list. Like, oh yeah, that's stupid. What's an example of that? Oh, Toby.

What's an example? Let me look. I was hoping there was going to be some mention of Fibonacci numbers and story points. Yeah, so like I was getting transcripts done of the podcast, but then I switched to using, I guess, the OpenAI...

transcribing thing. Whisper? Yeah. But it's like, like I ran into all kinds of problems with it. And so I had to feed it a glossary and then had to tweak things on it. So like one time, like I have written down here, I wrote this thing like glossary generator, right? And so it takes the, the whisper transcription feeds it to like chat GPT-4. And there's probably some mistakes in it. Like, can you make a list of the words that it got wrong? Right. And then I feed that back again.

So that was like just something I added because I was like, okay, this is wrong. And then I'm like, okay, now I have this list and I'm feeding it back and then it gets it. Yeah. Nice. You mentioned you learned a lot from that class. What are some of the pieces you learned that would involve telling a good story? The thing I learned from Christina, there's a lot in your voice, like a lot of emotion and power.

And if I am telling a story to my wife or something, even just like I was reading this book and it had this crazy story in it, it was like a nonfiction book. And I'm like animated and telling her all this, right? But then I would want to introduce the story for my podcast and I would be talking just into the void. I'm like recording the intro and there's nobody there. And I just...

don't sound like a person. I just sound so bored. Right? Like, I don't sound excited. Relatable. And so, like, that's hard. Like, I still struggle with that. But, like, that was the thing where she was like, yeah, this isn't good. Like,

You know, there's all these radio people in the class. And then I remember because she had me like, I was in this room and we were all in this big zoom meeting, uh, whatever I have to like practice reading. So I'm like reading the intro and, uh, she's like, okay, try again. But she's like, leave, like get out of the room. And then I want you to like run in as fast as you can and then like stop and give your intro. Right. And then I did that. And she's like, see, that's getting better. And it was like, she was like, she made me just like physically move a lot. Um,

But the idea was like to try to get some of that humanness of like how I would normally talk. It's like for whatever reason, like a switch would flip in my head and I'd be like, time to read the introduction to my podcast, you know? Oh, nice. How did he come across this class, by the way? Like, I think I found a link to this, the...

It's like Association of Independent Audio Producers. Is that the one? Yeah, yeah. Yeah, they have a class. So training. Yeah. Yeah. So I joined them and then they send out emails and they're like, hey, here's a class. And I was like, I should sign up for this. And then I was very nervous about it because I don't feel like I should be part of the Independent Association of Audio Producers. But yeah, it was fine. Yeah.

Oh, nice. So you mentioned you took another class with NPR as well, which was more about like, where can you add certain soundbites, not soundbites, but rather, what's the right word? Audio pieces to emphasize what the person is saying. What was that about? It was about that. Like where to add. What did you learn as part of that class? Yeah. Like, so

If you were to listen, I guess like Serial was like a really big breakthrough podcast back in the day. And like it, it was like scored, like it had like music and the music kind of

gave it momentum and, you know, kept it moving and made it interesting. And that was created by the people who made This American Life. And if you listen to This American Life, right, it's like a bunch of 15 minute versions of that. And they use music. Sometimes it's too much and I don't like it, but sometimes it really adds a lot to the episode. And so, yeah, I

I took a class where they talked about how that's done. You know, there's podcasts that are like full dramas with like people acting out a fiction with sound effects. But I just learned the very basics. And yeah, I found it very powerful.

And the thing that I learned was like, I, if I took like a, so I paid for a non, like a royalty free music service. And I found like, if I found like a rock song and I drop out all the instruments, except just the bait. Um, and then I can use kind of like a gritty sound bass. Uh, and then when you, you know, just like a repetitive bass chord when I'm introducing things. And then I drop out like that and you cut the bass and then the story starts and people are like,

you know, it gives them an audio cue that like, oh, something's changed here. Right. That was Adam talking, but now like, boom, now we're in the pretty cool, pretty cool. Um,

Guang, you gotta add more music. No, I was gonna say you should be taking notes, not I. How did you get this conviction to, you know, put in all this investment in terms of like learning new skills? I imagine, yeah, it must have been pretty, you know, daunting to be in that room with the people from the economy. Yeah. So I read this book called Ultra Learning and it's by Scott Young, I believe. Super good book.

Ultra learning, master hard skills, outsmart the competition, accelerate your career. It's quite a subtitle. So Scott Young was this guy who he finished business school and decided, why didn't I go into computer science? Like I like computers, right? I like programming. And so he embarked, you know, this was, I don't know, 20 years ago.

but it was right when the MIT like open courseware came out. So he embarked on this project, like I'm going to do the whole MIT undergrad, uh, but I'm going to hit it like full time as a job. And I should be able to do the courses, um, like do a triple course load and pass through all these classes. Um, and he, he did do that. I mean, you don't get a degree for just doing all the online MIT things, but he had somebody grade him. Like he got tests and

Whatever. And then he, I don't know, he did this a bunch of times. Anyways, he wrote a book about this. He called it like ultra learning. And I read it around the time that I transitioned to the storytelling stuff. And I guess the point of the book was like, hey, if you like really hit something hard in a short period of time, you can make a lot of progress, right? Other examples in the book included like people who

you know, develop a level of language proficiency really quickly and how they just invest a lot of effort and surpass somebody who spends 10 years on Duolingo. You know, they get there in three months, but just by like hammering it. So I think that that's true, right? So what do you want to throw yourself at, right? So I chose to throw myself at the podcast. There's people now, you know, I mean, you mentioned data science, right? It's like,

Sometimes if you encounter something new and you're excited about it, you can just really invest a lot of time and level up pretty quickly. Nice. Taking a step back, right? Like you're doing this all like while having a full-time job. How did you balance this? Like, did you treat this as just like kind of like a hobby that you like do on the side or? Yeah. I mean, so it started off when I wasn't

putting much into it, then it wasn't too hard. Like before I really started focusing on, oh, let's make the best episode I can, then it wasn't that challenging because it didn't take up that much time. At some point, I started waking up at five o'clock. And so I would work for two hours, like from 5.15 to like 7.15. Then I would get ready for my day and then I would work.

I would just do two hours of podcast work before I worked each day. And like, sometimes I wasn't super, it probably wasn't my best hours for working, but cumulatively there's actually a lot of hours there. So, so that worked very well. So it was just like putting in the time. I stopped, I moved the time from five to six because like eventually I did it. Like, I think after like two years of that, like,

I was just like, that's like kind of sleep deprived or I don't know. Like it ended up, I ended up switching it because my wife was just like, why are you an asshole all the time? I didn't actually say that, but it was like, I felt like I was, I was wearing a little bit, uh, my social niceties. But yeah, so that was a big way. I just, I just spent two hours on it each morning. That's a big commitment to be honest. Yeah. I mean, I struggle with this all the time.

Is there a clear, I mean, you know, you've already talked about sort of the goal is to kind of keep on

improving it and then produce the best podcast that you can. How do you go about goal setting, I guess? I don't know. Yeah. I've been thinking about this thing like goal drift. Start with a specific goal, you know, doing the podcast because I want to learn about more technical stuff or I want to ask a person a question who I read their book and then like, you know, get some attention and then you're excited about it and then it's like, well, maybe I'm going to be Joe Rogan with hair. Like, I don't know. Maybe that's my next stop, right? Uh...

And then, you know, then I get into the storytelling thing. Nice, nice. What, I guess, what's your like current goal if you have one? So my current goal, it kind of relates to something you were asking, which is, yeah, if somebody has this big crazy story, like that guy who did Lisp in space, like that's amazing, right? But like what about like people's everyday lives, right?

How can that be interesting and how can people learn from that? Because I think, well, first of all, there's a limit of people deploying Lisp into space. But also there's so much to learn from just everyday stuff that happens to people. But how do you make that entertaining? I think that's a big challenge for me. You can write the science fiction book where the world is on the line and if you don't save things, the Earth is going to explode.

But like, can you write the story where it's like very compelling, but it's about like something much smaller, right? Like somebody raising their kid or whatever. That's a metaphor. I'm not working on any of those things. But like, I was talking to somebody recently about something I was working on at work and how I was given this ticket to work on this area I wasn't familiar with. And like, I thought I knew how to solve it and I was working on solving it.

In turn, I was wrong. I didn't understand what I was doing. But it was like three days later when I figured out I didn't like I was doing it wrong. Right. And like I was new to this. So there's expectation like I could get feedback and help, but also it had been three days. And so I was like,

It's too late to like reach out and ask for help because they're going to be like, well, what the hell have you been doing? Right. And so I was explaining this to somebody and I thought it was like a very much my weird headspace. Right. That I was going over this in my head, like, oh my God, it's too late to ask for help. And this person was like, oh my God, like I think about that all the time. Like it's too late to ask for help. Like I'm stuck by that.

And then that made me think like, there's all these things, the small things of everyday work world and like, how do you make those interesting and compelling stories? Um, so that's something I'm thinking about. I don't know that I have an answer, but yeah. I guess the, obviously if it's crazy, it has its own appeal, but then, you know, the further away you get from crazy, like the more normal it is, like more relatable it is. Right. So there's much more of an emphasis on how well the storytelling is versus just like sort of you doubt the facts. Yeah.

in terms of phobia, it's a little outlandish. Yeah, but like, how do you make it interesting, right? Because like our days can be boring, right? But like, where's the pieces where it's not boring, right? And I think it has a lot to do with vulnerability, right? Like if you're able to share the things that you are struggling with

Like internally, like that can be a lot. There can be something interesting there. Like even this ticket that was a problem for me was super minor and boring. And if I described it to you, like you wouldn't care.

But the fact that it got me worked up and I was worried that they're going to think I'm dumb and how did I think that this way would work? And I have to hide it. How am I going to catch up so they don't know I went down this-- yeah. That's where it gets interesting to me. ZYPHUS LEBRUN: Nice, nice. So speaking of storytelling, so DevRel, so developers relations, there's also, I imagine, a ton of storytelling there. How did you first get into it, I guess?

for the management story. Now, fast forward a little bit. Yeah, I mean, like I had the podcast and so somebody reached out to me about a developer relations role. I was like, yeah, I like, you know, communicating to developers. Let's give it a try. And yeah, I didn't know what I was doing.

And the person who hired me had never, they didn't know what developer relations, I mean, I guess we all had ideas, right? But so I started thinking that like I would go give a lot of talks at conferences and then, you know, we tried to do meetups and I wrote like tutorials talking about our product and we didn't see a lot of success. But then we reached out to this guy, Mitch Weiner. He's one of the founders of DigitalOcean.

And he said, like, well, you just need to understand the people who might be the customers of your product, like these developers, like what problems they have. And then like just solve those problems, like write down the solutions. And we were like, OK, and then what? He's like, that's the whole thing. Like that's like people didn't know how to install MySQL onto a Linux server. We wrote that down. We put it like on the DigitalOcean website.

And we didn't say like check out DigitalOcean. I mean, maybe, but like we just told them how to solve their problem. And like that happens to be obviously those people, you know, might be interested in getting a virtual private server from DigitalOcean, right?

So that's how I got my start. And we just tried to help people with their problems, right? One of the big first things I wrote that the people really remember me by was this article about JQ. JQ parses JSON, super idiosyncratic tool, I guess, right? Like,

And so I just wrote a tutorial for how it works because if you understood kind of the logic behind it, like it made sense. It's like its own little JQ world. You can, it's actually Turing complete. You could build whatever you want inside of it. I think it was on Hacker News recently, somebody built JQ inside of JQ, like using the Turing complete. Oh, wow. That's fancy. I just spent a lot of time writing down, you know, like here's how you use it and explaining things to people. And then that did very well.

you know, it showed up on Hacker News, people were on our website, they learned about our product. And that was like how I started to, yeah, to learn these skills. So I mean, I guess that's not really storytelling. It's more understanding developers and what problems they have. So one follow up on that, like when it comes to developer relations, you see many people in this role from different companies, and they all do it very differently.

Kind of going by what you said earlier, in many cases you see some people building kind of a tutorial, working tutorial of sorts, and they would publish it on GitHub. It's like, here's how you can use tool X to achieve Y, which is basically a way to show how you can use one of their products to solve your problems. In some cases, it's tutorials like a blog post, in other cases, like a conference talk, for example. What are the parts which are not visible outside to people?

which is sometimes talking to customers, for example, to understand what their problems are. So if I just look at the words like developer and relationships, what are the aspects here which are not public facing, which happens behind the scenes? Yeah, I mean, that would be one of them for sure. Like talking to people, using the product, seeing what problems they have, maybe paying attention to where people are just talking about your products or competitors or whatever, seeing what issues they have.

One of the problems is like developer relations is a weird role. It means a lot of different things to different, depending on the organization, right? I mean, I guess that's true of any role, right? But like some people is communicating feedback that, you know, users of the product are getting to the product team, right? So it can look a little bit like a PM role or something, right? Where, you know, developers are using this API, they're having this issue, like how can we prioritize this?

So I worked at Earthly. It was like a seed stage startup. And like our big problem, you know, was we were competing obscurity, right? Like nobody knew we existed. If you worked in developer relations for Amazon on AWS Lambda, like everybody knows it exists, right? So then it's a different type of problem, right? You don't need to let people know that Lambda is a thing.

Yeah, maybe it's much more relevant to provide tutorials that show how to use the latest feature. Or yeah, that part where you're feeding feedback back to the product team. So it varies a lot. But yeah, I guess I did a lot of like awareness stuff, right? And that's where that DigitalOcean perspective really made sense. Because if you go like, I went to a meetup to talk about Earthly. It was like an online meetup.

And, uh, like there was the guy who hosted it and there was one other person. And then I gave some presentation and then at the end I was like, any questions? And the, the, the one person who wasn't like the host was like, so this is a command line tool. I was like, yeah, no, it is a command line tool to pay. And then, uh,

But the thing is, because who wants a meetup where various dev tool startups come and show what they've built, right? Nobody does, right? So I think Mitch Weiner's point was like, what problems actually people have? And you don't need to sell them on your product. Just help them, you know, solve their problems. And often it's tangentially related, right? Like I remember...

Earthly, for example, really good at doing builds for monorepos, which can be a challenge. And so we wrote like lots of stuff about like, here's how you can build monorepos, right? Not just here's how you do it with our tool. Like, here's how you structure it. Here's best practices. It's like educating people. Those people, you know, we think they would really benefit from using our product. But just putting that out there, they're aware of us and they know, you know, maybe when they're like, hey, we'll

What build tool should I use? They might check it out. So in a way, talking about goal drifting, at the beginning of the podcast, like you mentioned, your goal was to be this amazing programmer who knows how to solve all these problems in the code. On the developer relationship side, I would say it's slightly different where it's

little more breadth than depth. Maybe I'm getting that wrong. But if that's the case, like in a way that goal has drifted, considering that, do you want to stay on the DevRel path or would you consider changing it? Like you think I've drifted from my technical roots, I guess. Yeah.

I'm curious about that as well. Because like when you said that, right? Like I was like, ooh, like kind of being like an engineer's engineer. Being really like a drill down. Is that still important to you? Like, do you still want to be that? Or after all this experience, you were kind of like, you know what? Maybe that was kind of a pseudo goal. Yeah. Or part of the journey that got me to where I am. Ooh, that sounded pretty. Yeah. Sorry, sorry, sorry. I don't know why I wanted to be

the best engineer. Like, I don't know. It's just, I wanted to. But like, there's all these people that I looked up to in that time, right? I'm trying to think of specific people. Like, Joel Spolsky, I remember he had this blog talking about engineering, like, back in the day. It was the guy from Steve Yeagy or whatever. I don't know. There was all these people. And I was like, you know, I want to know all the things that they know.

Um, like I want to be that great. But like, if you think about it, the reason we know about them is because actually they're communicators, right? They're explaining problems to us. Like I thought this guy has a blog cause he's the most amazing engineer. Um, but no, he, he, he's,

I know about the things that he's done because he talks about them, right? Like what he's actually good at, like all these people I looked up to, what they're actually good at was communicating, right? The person who wrote the book that I wanted to ask questions about how to do, you know, whatever functional programming, like it's not clear they were the best functional programmer in the world. Hopefully they were decent at it. But no, they had written a book, right? They had spent a lot of time

communicating. So I think that actually, I maybe realized that my goal was misplaced, that there was a larger goal or something that, yeah, I wasn't seeing that all these people who communicate are the people that I look up to. And it can be super impactful if you can take something and explain it in a way that lets it crystallize in people's minds. And I don't know

that I'm the best at it, but like it feels very valuable and important. Yeah. And so that's what I'm going for, right? And like, it's weird because developer relations, it feels like it's a good rocket because I like communicating to developers, right?

And if I can find a place where they value those skills and it can help impactfully, you know, grow their business or whatever. And also I get to like write about why we should stop using YAML like for everything or whatever my perspective is. Like it feels like a super good, it feels like it shouldn't be something that I'm paid for, but it seems like people are willing to pay. Yeah.

oh why we shouldn't use the animals for everything well there's the number uh hacker news number one post yeah that was like a really nice uh full circle in some ways um that yeah and that's actually quite profound that i need to think more yeah if you if you think of all the people you look up to right um like i was looking up to them because i thought they were the best but but like i would never have known about them if they didn't

invest time into into communicating right like i remember reading all these carl sagan books when i was a kid i loved them um you know like oh carl sagan is the most amazing scientist in the world although he was amazing science writer right like i think he was a good scientist but that's not why i know of him uh i know of him because he's a science writer uh communication

is everything, right? The people telling stories about the builds breaking at Opertel. The person I learned the most from, I think he was just really good at telling these stories, right? You know, like somebody would be like, oh, yeah, I got called in on the weekend, like turned out the disc was full. But Richard, that's not how he would tell the story, right? Like he would give you breadcrumbs. This is like...

So I get this call, I'm laying on my couch, I'm watching Lost and I'm like, I need to drive in. And, you know, and he would like, they're like, oh, Richard's got another good one. Oh, was it this? Was it that? Did the router power out again? Yeah. And it's like, I learned a lot from Richard, but only because he let you kind of live that debugging experience, right? Like you got the vicarious learning of that battle. That's just because he was a good storyteller.

All right, that was the show. You can go to softwaremisadventures.com to find a video version of this. There will be a link in the show notes to that page. And they have many other great interviews with people far more accomplished than myself. So you should check them out. And thank you for letting me share this interview on my feed. Yeah, and until next time, thank you so much for listening.