#48 Shawn Wildermuth encourages us to make decisions no matter what
Transcript
⚠ The following transcript was automatically generated.
❤ Help us out, Submit
a pull-request to correct potential mistakes
Tim Bourguignon 0:06
Hello, and welcome to developer's journey. The podcast shining a light on developers lives from all over the world. My name is Tim Bourguignon, and today I receive Shawn Williams. Sean has been tinkering with computers and software since he got a Vic 20. In the early 80s, as a Microsoft MVP since 2002. He's been involved with Microsoft as an ESP dotnet. Insider, and client dev Insider. He has authored eight books, and innumerable articles on software development. You can also see him at one of the local and international conferences. He's spoken at many, including tech heads or CD n DC vs. Live their intersection makes they've teach Deaf connections, and they've reached and probably many more, and he's one of the wild minds. Sean, welcome to their journey.
Shawn Wildermuth 1:03
Thank you. Thank you, I'm really glad to hear
Tim Bourguignon 1:05
you have to tell what is a wild mind.
Shawn Wildermuth 1:08
It's my company. So we're called Wild or mind, which is sort of a plan my name. And we do training, mostly, we do a little consulting as well. And so it's just a what I think is a clever version of my name.
Tim Bourguignon 1:24
It is it is, thanks for clearing that out. Okay, but let's backtrack. How did you go from that victini in the 80s, to being an MVP in 2002?
Shawn Wildermuth 1:38
Well, I guess I'll start at the very beginning.
Growing up I was our family was really poor. And I didn't even know what computers were at all. But luckily, we lived a few blocks away from a pretty affluent neighborhood, and they had a computer at their house. And I used to hang out there. And I learned about having a computer and I was just obsessed, as soon as I got that first computer, you know, doing a little programming here or there and trying to figure this all out and meeting with other little geeky kids about how they did it. And I was lucky, lucky enough that when I was 16, I got hired at this little company for a summer job to write software on this old z 80 system, which some people might remember. And that was sort of my my entrance, I eventually dropped out of high school, and dropped out of college because I was just enjoying writing code too much. And for a long time that's left me in this sort of like, you know, feeling like an imposter because I don't have the CS degree or the master and this or have a doctorate like a lot of the other people in software. In some some of it has been that I've just been really lucky to find good mentors along the way. And some of it is, you know, our industry is so driven by knowledge versus credentials. It's a little different than than the normal sciences, at least in the US, where what degree you got, where you got it is, is super important about the kind of job you want to be doing. And so I sort of went from job to job. For years, probably the first 14 years, 15 years of my career, I've been doing this for who let me think
34 years now I think, and
just trying to learn whatever I could, on the way my my specialty when I was getting started, was actually learning being hired someplace where they didn't have anyone or could find anyone that knew a particular system or software or technology. And there was a lot of these little languages, you know, running around back then, pre internet, not all of that. But because I had this computer growing up, I wasn't afraid to just try and fail and try and fail until it worked. And that has been so crucial to sort of my career path. You know, I never really planned on what I wanted to do in this industry. I didn't think oh, I want to be a manager or want to do this. I actually kind of wanted to get out of it. I didn't want to be a geek. So that you know, anyone who's seen a picture of me knows I'm a pretty hardcore geek, right? But it wasn't growing up. It's not the picture I wanted, you know, when I would go to parties in high school. I didn't want to tell people that I like dungeons and dragons and played with computers. I you know, I'd rather tell them that, you know, I wanted To be a rock star, I don't know what you know, as many decisions in my life have been driven by my desire to make women smile. Being a geek didn't seem one that was all that attractive. But it's something that I had, you know, an innate gift for him. It wasn't until really, I got into my 30s, which was 12 or 13 years in that I just went. You know who you are, right? You love doing this? Why are you fighting so hard and just sort of giving into it? I always thought this was sort of a stepping stone or distraction until I figured out what I really wanted to do with my life.
Tim Bourguignon 5:40
Did you remember when that happened was there was there a moment,
Shawn Wildermuth 5:45
there was I had moved to Boston. And I found this job at this medical software company. And there was a manager, I guess he was my manager, maybe just the lead, I think it was the lead, Ron Rinaldi and he was so crucial to my development as a as a developer, because he mentored me in a way that I've sort of stolen my whole career. And that is, instead of like, hammering what I was doing well, and what I wasn't doing well, what he was really good at was making me want to be a better developer. So early in my career, I could make stuff work. But it didn't, my code wasn't very maintainable. I didn't like to write comments, I didn't like to be structured, I just could sort of hack stuff together, it was, you know, something I was good at. But it didn't mean that the person coming behind me two years later was gonna be able to make sense of it. Because I didn't think about code being, you know, that good code was beautiful code and was easy to read. And that this is how you planned out code. And so watching the way he did code and intermingling my code with him with his code made me want to write better code. And having that example, was so crucial to me wanting to just take this whole job seriously. I'd sort of, you know, gotten by, by just being a hard worker, and, and smart, instead of wanting to really apply myself for quite a long time, because, you know, I was always the one computer guy in some small company for for quite a long time. And so I didn't really have that exposure, I wasn't going to use your groups, and I wasn't, you know, I was pretty isolated in that way. And then when I started to take it seriously, I realized how important all that was not just a software, but to me, that, that being good at what I do, and being able to explain what I've done and, and create good software that, you know, not just that has fewer bugs, or that runs faster, but that every line of code we write lives for such a long time, that the value in creating good code isn't just whether your bug count is low, and whether it runs efficiently, but also, that the company that has invested in this code can continue to use this code, and to maintain and enhance this code for years to come. There's an old adage, I'm not sure it's true anymore. But it certainly was back in the c++ days that every dollar in development that spent only 10% is writing new code that 90% is in is spent maintaining code. And so getting that code right the first time so that you can maintain it pays off huge dividends later on.
Tim Bourguignon 8:53
Yeah, that's that's basically I think, what what Uncle Bob wrote in clinco, that's you spend 10% of your time writing code and 90% reading it that would match at least with us?
Shawn Wildermuth 9:05
Sure, sure. Yeah. A lot of this goes back to McConnell's code complete book that I think is still in print. But that was the one that I dove into, and really was like, Oh, you know, I want to be good at this. Because the reality is that I've never been very detail oriented in our job. Our job as software developers is being detail oriented. I'm on the whole. And so in some ways, I was always a better architect than I was a coder. And I think that be that continues to be true, but figuring out I think that's one of the challenges for people in this industry, is to figure out where your strengths are and where your weaknesses are. And try to augment the strengths and the weaknesses. What I find is that people are tend to be more interested in finding in getting a title that makes Some seem more important, or that includes arrays or whatever the case may be, then then really finding the right fit. You know, I think most developers are a jigsaw piece. And we're trying to figure out where we best fit in the puzzle, whether that some people are better at writing plumbing code, some people are better at writing client code, some people have the aesthetic for doing UX work, some people have the head for database work. figuring out where you want to be in what you want to be doing, I think is so crucial. And when people come out of college or boot camps, or wherever they come from, they don't know that yet. There's no way to do that until you've done a bunch of different things. And you're like, Oh, this is where I feel the most stretch, it's not about what comes easy. It's about in some ways where you can grow. Because our job as developers, I keep on saying, isn't to write code. I know it feels like we're writing code. Our job as developers is to learn that may be learning about the business you just got hired into and how they do business. So that you can turn that in and transform that through code, whether it's learning a new skill, because the speed of technology moves so much. And so if you think you're coming out of college, or a boot camp, or even, you know, changing jobs after 10 years, in, you know, everything. That's a, that's a death sentence, right? Even people who have, I did a talk at a fox pro Users Group A few years ago, and even people that are using an old technology and have feel like they know it inside and out, they are probably learning something deeper, every week or every month of their career. And that that I think, is what, what draws people into this job. So, so much, it's what drew me and has kept me here for you know, 30 plus years now, is this desire to be excited about something new,
Tim Bourguignon 12:01
I would like to come back to to Ron, you're your mentor, you mentioned before Sure, you remember how he went up and pique your interest and get you interested in writing better code.
Shawn Wildermuth 12:13
It's interesting, because Ron, Ron was so laid back, it wasn't, he wasn't trying to encourage me even, he just set such a great example, that when I had to interact with his code, and I'd have to figure out the way his code worked, so I could write this other piece that goes with it, that I was like, Oh, this is the way coding supposed to be I'm not supposed to be digging into some terse code. Ron style was never to, to push people or anything, it was just sort of like, well, wouldn't it be easier if or have you ever thought of doing this, it was this very,
almost
Tai Chi, a way of, of mentoring, where he could sort of just push you in the right direction, and very subtly, without you really, really knowing it, and to improve the quality of everyone's code. You know, in looking at that, and this is before pair programming and code reviews were really that much of a thing. And this was back in the VB three VB five days. So it's not like, there's even a language that matters, the things I've learned in writing, good code apply to pretty much any language I've worked with, you know, I get frustrated, when I hear people want to just hack up the JavaScript, JavaScript doesn't matter. It's not a real language that I, you know, I'm gonna write good C, sharp code, or whatever the server side code they're writing, and I'm like, it's all code. It's all just, you know, 80% of it, is, you know, while if, and branching, right, it's 80% of most languages, until you get maybe into functional languages, is really all the same. You're a good coder, you're not a good C sharp coder or a Java coder, you're, you should be a good coder. That's what we should be, you know, striving for, even in the midst of deadlines and trying to get that last 10% of a project done, which for me is, you know, it's the hellscape of down the wire. I'd love the first 80% of a project, but I think most people, like me hate the last 20% of triaging bugs and working with deadlines and staying late and you know, yeah,
Tim Bourguignon 14:41
I can feel the pain. That's part of the job we have to do, but don't really enjoy doing it, I think.
Shawn Wildermuth 14:47
Yeah, and I think, again, I think that's the nature of where I feel like I've succeeded in figuring out what works for me, you know, At some point, let me think back in 2000, or maybe 1999, I went to one of my first conferences windev in Boston, might even been earlier than that. But I think that's about right. And I met Chris cells, who was another person that really helped me and mentored me. And he was speaking at the conference, and I sort of pulled him aside after his talk, and was like, I want to speak at conferences. I like the idea of, sort of, you know, in truth, I like the sound of my own voice and the ego hit, but I also like sharing what, you know, I've learned with others, how do I do this? And he had encouraged me, you know, he said, the best way to sort of have a resume for this thing. So have you thought about writing articles. And I hadn't, like I didn't even occur to me to write for a magazine or something like that, just before I even had a blog, I think. And that opened up my like, I decided to write some articles, and beg people to let me write some articles so that I could speak at conferences, which is really the backwards way of doing it. But what that taught me was that I like the break down, like breaking down a technology and explaining it to people, because that's what you really, you know, in doing a conference talk or doing something else, you know, a book or a video or a course, that's part of that challenge. And so, somewhere around what 18 years ago, is when I started to think, Oh, this teaching and learning thing, is something that I really enjoy, because the the problem really tickles that figure out gene without having to necessarily have that last 20% of project work. It was just sort of this mythical place. And I think in every Developers Life, at some point, they come to that road of, do I want to just be an individual contributor? Like, is that really where I'm best? And I love it. And this, you know, having the challenge of code every day, do I want to become a lead or a manager where part of my work is working with other developers and helping them Excel becoming mentors, that sort of thing? Do I want to go into teaching do I want to start my own company like, coding on its own, usually has that several moments in people's careers where they have to make a decision about what they want, because, frankly, a lot of coders don't make great managers. But some do. Not all coders make great teachers, but some do. Not all coders make good architects some do. And so sort of figuring that out, has, has been really important to me, one of the things that has driven my sort of life's path, for good or bad is this, there's a quote that says, in any minute, in any moment of decision, I believe it's Teddy Roosevelt, but I could be wrong. In any moment of decision, there's three things you can do, the best thing you can do is the right decision, the second best thing you can do is the wrong decision. And the third thing you can do is do nothing at all. And that idea has really driven me to when these moments of decision and a career come to make a decision to take the risk. The you know, the idea of courage is being afraid and doing it anyway, instead of, you know, being fearless. That all happens a lot in this career. And it can be very comfortable to stay in one job for a really long time where you're doing the same thing day after day, and it gets comfortable and you've got a mortgage to pay and you've got kids to put through college. And that's certainly, you know, that is a choice just like finding a new challenge or learning on the weekends or going to that conference or wanting to speak at that conference, whatever the case may be. All those choices you can make. And and I think that's a challenge in this business is where do you want to fit in? Where do you want to be long term because there's always going to be, you know, 19 year olds coming out of boot camps are college that can code.
Shawn Wildermuth 19:33
And
Shawn Wildermuth 19:35
as developers, we have to figure out where we fit. You know, some of us just love code so much that that's, that's where it comes in. There was a because I'd met Chris the there was a moment in 2000 when Chris had asked me to help work on a project and Up to that point in my career, I had been, you know, the smartest guy at a tiny company or the big fish in a small pond, whatever you want to be called. I like being the Savior. Oh, you know, this isn't working. Let's get Sean to look at it. Oh, it worked. Whoo, you know. And so when, when Chris asked me, this was to come work for development, er, which at the time had Chris cells and Don box and Tim evolved and all these people like, incredibly admired, and that, frankly, scared the shit out of me. I'm not sure if whether we can curse on the show. But and that was the most, that was the most difficult decision I've ever made. And that was, do I stay here in Boston, because I also needed to move across the country to join them. Where I know I'm not the smartest guy in the room. Am I willing to go to where I get that ego hit by being the alpha developer or whatever you want to call it? In a company, in go to where every day I'm going to work. And I know that I'm not the smartest guy there. And because I took that risk of, of,
of being found out or
being challenged intellectually, every day, that changed everything. For me, it made me realize that, oh, I don't have to be the savior. I don't have to, you know, be right. In every case, you know, there's a very humbling thing about being in an architecture discussion or coding discussion, and being wrong and being able to admit it does actually happened with with Chris back in the C plus plus days when we were doing some stuff. And he said, Well, I don't think you're using the you know, B strings or whatever it was back then maybe a C string, I don't remember anymore. correctly, you know, maybe you should look it up. And, and so I asked him, Well, how does it work? And he goes, I'm not sure let's, let's find out. And so we we sat there and figured it out, and him saying to me that he didn't know something, you know, I just assumed he had little literally had written a book on this technology. But that he didn't have it as fingertips told me, oh, none of us have to have this all at our fingertips. You know, this is sort of the fallacy of the whiteboard interview, is that's not how coding happens. And being willing to say, I don't know, is such a crucial, crucial skill, to put yourself out there and go, I don't know, but what we can find out or I can find out or let's figure it out. It's just, that was such a turning point in my career, being able to, I didn't have to compete to be the smartest guy in the room. Every time I could just let people
Shawn Wildermuth 23:01
you know.
Shawn Wildermuth 23:03
People bring their own skills and benefits that meshed well with mine, instead of thinking that I had to be the best at everything I did.
Tim Bourguignon 23:11
Well, that is wrong. Thank you. That's very, very good. Very good advice. I would like to come back to these making a decision you mentioned, do you have a personal personal strategy to vet your options and go at a decision or make a decision?
Shawn Wildermuth 23:32
Well, like the like the phrase says, sometimes I don't know what the right thing to do. And so we'll make a decision knowing I can change that decision. Right. And in that can be a little scary. If you're like, I don't know, whether this new job is going to be any better than the one I'm in or maybe it'll be worse, you know, the devil, you know, and all that. But you know, and I've, I've probably left jobs earlier than a lot of people and that has its own problem. But sometimes just making a decision, even if I have no idea what the right one is. Because changing jobs is such a common thing in our industry. I will talk about that for a minute. Because one of the only my own company has as forced me to not interview for jobs much anymore, right? Because, you know, obviously, running my own thing, I don't have to go and put my my resume or CV out there. And then set but I miss the interview and I really enjoyed interviewing, which I know is sort of weird. In a lot of people's mind it because I sort of like the game of it all. Because one of the strategies I tell people to do when they're interviewing for a job is to make sure that you're interviewing them to this is to me is crucial to figuring out whether it's That decision, you know, to change jobs is the right one. One of the things that I used to do in interviews is though I'd ask them how long in advance they had to book a conference room? Which seems like a weird question for a coder to care about. But it's an indication to me of how many meetings versus how much work they could do, right? Because I don't want to be at a place that just spends all day in these meetings, that you just sit there and drudge through instead of being able to actually get work done. There are questions like that, that you can sort of get a sense because you have to figure out whether you want to be there, as well, I find too many people that interview are so are so sort of begging for the job that they haven't figured out whether they're a good fit, you know, they're so worried about that, that they fit into the company, instead of figuring out whether the company fits with them. I see this over and over and over again. And then they start, they're excited. They're like, Oh, this place is toxic? Well, yeah, yeah, that's why they were looking for new developers.
Because everyone else has quit, you know,
which just happened to some companies. So that moment of decision, you know, I would rather make a wrong decision than to sit there and just be stuck. But that does take a certain amount of courage, that takes a certain amount of, I'll be okay, or faith, or I don't know, what the, you know, probably a mix of a bunch of those, making that the, you know, taking that risk is a risk, everything's a risk. I, at some point, I don't know, maybe 10 years ago, I was in a different relationship. And I really thought that she didn't like the insecurity of me running the business. And what I mean by that is feast or famine, we'd have money, and then suddenly, you know, fighting for the next contract and trying to find it and all that. And so I took a job at a consulting company, and I was miserable. Nothing wrong with a consulting company, just you know, maybe I'm a little bit of a control freak, but it was just difficult. But I, you know, there was a security and you get a check every two weeks. And it's reliable. And I didn't realize because I hadn't gotten buy in from my then girlfriend. But she didn't care about security, I just, I thought she cared about security. And so I made this horrible decision to join a consulting company, instead of doing what I really wanted to do, which was, you know, do contracting work and to teach and to these other things that I'd already been doing. And that was a big lesson for me that, that, that not only do my decisions affect me, but everyone around me, so you know, if you're married, and especially if you have kids getting buy in, for that level of risk is something else that, you know, I think is so crucially important. You know, the problem with my career path has been that when I have worked for companies, I haven't spent a lot of time at companies because I get bored quickly. And I sort of see the, you know, the grass is greener, and that sort of thing. I don't suggest that necessarily. But it has exposed me to a lot of different kinds of environments. And that, that, you know, that is what's driven me in this career. I certainly, you know, every decision I made wasn't the right one. But by making more decisions in my life, I have opportunity to be lucky more often. It's, it's sort of like gambling. You know, people here in the States, a lot of them play the lottery. And they, they argue that, you know, you can't win if you don't play, I like to think of most of the decisions I make, that the odds are much better than, than the lottery. But it still is this if I don't, you know, if I'm not open to what's going on, or if I don't put myself out there at a conference and, and engage with other people and, and, you know, fight my introverted instincts, I'll never, you know, see and hear and, and know what the the next opportunity is. Because the last thing I want to do is to stagnate and what I mean by stagnate isn't Oh, my God, I know Angular, but I don't know react yet. When I mean, is stagnate is becoming bored with what I'm doing. It's not really about the technology. To me, it's about the it's about the challenge. Because when, when I would change jobs, the big challenge in changing jobs wasn't being able to work with the new, you know, JavaScript framework that I'm not allowed to work with it. My old company, it was I was moving into a company that had a problem they were trying to solve with software. And so my job was to figure out what that problem was and figure out how we could solve it with software. And that's a much. That's a really interesting problem for me.
I work for, I did a consulting gig with a company in the middle of the country. And what they did was they delivered new tractor trailer trucks. So their problem was that someone would drive a truck that had three trucks attached to it to these different dealerships. And then when they were done, they just had a driver that didn't have a vehicle anymore. And they were trying to figure out how to schedule that better. That's way more interesting than learning another, you know, another way to use Python or these other things, to me, their particular like business problem was really fascinating. And I was figuring out a way to model that with software and to help have software help them, figure it out, where they were just using yellow pads to do before, was incredibly rewarding, regardless of the technology I was using, but it took me 15 years to figure out that the technology isn't as interesting as the actual things we're building.
Tim Bourguignon 31:21
I guess there's no shortcut to learning this, you have to go through the curve of learning the technology and being hyped about it, and then realize that there's something beyond the technology and then realize that the technology is just the little thing that you have to do to get at the real problem.
Shawn Wildermuth 31:38
Absolutely, absolutely. And, you know, I think that comes with experience. And that comes with, you know, I think it's too easy in colleges and boot camps to have less than challenging projects, right. They want people to be able to succeed. But it's also, you know, I used to say, I don't think it's true anymore, now that I've talked to more educators, but I used to say, people come out of college with a bachelor's degree in the US knowing how to write programs that average grades, right, that's it, that's all they learned was they learned this depth of knowledge about how computers work. But the reality is that most of the software we write doesn't touch, you know, the registers of a processor and to understand, no one's writing their own source algorithms or their own link lists. That's it just not. We don't write code at that level anymore.
Tim Bourguignon 32:36
Yeah, that's true. That's true. Um, we're running away from our time box. And I would like to touch one subject before, before we end, you dispensed a lot of a lot of very good advice. And from that I have so much to quote, it's, it's fascinating. I know you're writing a movie, or you're creating a movie, which might be full of quotes as well. Would you mind telling us what it's about and why you wanted to create such a movie?
Shawn Wildermuth 33:06
Well, it's interesting, I started working on the movie about two and a half years ago, just as sort of a whim. I've always loved film, and especially documentary films. And I felt like our industry had a story to tell. I wanted to demystify what software was about, but also talk about who's missing in software, the fact that, you know, women make a smaller percentage than men, at least here in the US, it depends on where you live. But in the US, we have a particular problem with black and Latino and Latina developers making up, you know, small, single digit percentages of the actual developers. And I wanted to figure out why I don't really have a solution in the film of how we can simply fix it. But it was a, again, another interesting problem that I wanted to delve into. that the movie really came out of this moment in my life where I was reading an article about women in technology, and women in programming specifically. And I started to think back and realize I'd never worked with an American woman. As a developer. I'd worked with technical writers and testers and but as a software developer, no American women. I've worked with a number of women from Indian China, Vietnam, but no American women. And it wasn't that I hadn't worked with them. that bothered me. It was that I didn't notice. Like, it never occurred to me that I'd never until I really started, like digging back into my memory memory. And at that moment, I felt like I was sort of part of the problem, right? When I thought of a developer, I thought of what they looked like and that what they looked like, was a white male with cargo pants. Right? That was The picture I had of what developers looked like, you know, probably Birkenstocks, or maybe just flip flops, but
I was feeding into that same
stereotype. And that that bothered me enough that I wanted to tell a story about where we came from the fact that the first developers were all women. And at one point, software development was 100% women. And I thought that was a story that hadn't been told, and one that I hoped I could tell. So we've done interviews with 50 different people, software developers around the world educators across the United States. And we're in post production right now, we were hoping to release by October. And people can go look at the film at Hello, World Film Comm. There's a little teaser up there to talk about what we're doing and why we're doing it. And something that has me really excited right now. It's sort of an extension of the teaching I do. But in a documentary film, the teachings a lot more subtle than
than just showing people how Angular works.
Tim Bourguignon 36:11
I'm looking forward to it sounds fantastic.
Shawn Wildermuth 36:13
Yeah, it's been a it's been a good ride. And I'm excited to finally get it out into people's hands and see what they think. And see if I'm right or wrong about some of my assumptions. I'm sure you are.
Tim Bourguignon 36:28
I'm sure you are. Okay, unfortunately, we are really coming to the end of the time books. Do you have one last advice for newcomers coming out of whichever boot camp University they come out from? And starting in the industry? What would you recommend them, I wouldn't
Shawn Wildermuth 36:45
recommend that you that all developers in every stage of their career, need to approach it from a place of humility, that you can't know everything, you won't know everything. And at some point, you won't remember it all. Even if you think you know it, and that we're all struggling in the same way. We're all dealing with the same bugs. And so when you think you're struggling with a problem, and that makes you a bad developer, or you're not good at what you do, everyone's making that same struggle. And then on the other side of it, if you're, if you're if your life is filled with a tinge of arrogance about how good you are at coding, usually, most of us take that as as a fact that you feel inferior, and that you need to prove it to the rest of us. So stop fooling yourself because you're not fooling any of us.
Tim Bourguignon 37:40
Amen. Thank you. If people wanted to, to get a catching you and start a discussion, where would be the ideal place to start?
Shawn Wildermuth 37:50
I'd start with my blog wildermuth.com. There are links out to the film there to my PluralSight courses to my Willer minds, courses, everything sort of starts right there at the blog. I'm also on Twitter at Shawn wildermuth. And feel free to say hi there as well, because I'm probably on there way too much, probably watching my follower count way too hard. But you can certainly reach out there as well. I post on my blog, I tried to post about once a week with some technical content. And then I talked about everything I really care about
Tim Bourguignon 38:27
any place to catch you up live at the conference. So in the coming months.
Shawn Wildermuth 38:32
No. So I've taken this year off to finish the film. The first conference I have booked right now is there is believe it or not a Arctic conference called Arctic comp, or Antarctic comp, because it's a cruise along Antarctica. And that's going to be happening in January when it's warm. And it artico
relatively
crazy. Yeah, it is crazy. That's crazy. And now, we'll share a link to that in the show notes as well. But that's the next big conference I'm doing. I'll be at the Atlanta Code Camp later this year in October that we don't have dates quite yet. And a couple of other local things, but I won't be doing conferences this year so I can get the film finished by October.
Tim Bourguignon 39:22
Sounds cool. And he also in your place you would like to mention,
Shawn Wildermuth 39:26
I just I'm publishing new courses on courses that will remit minds calm. Let me say that again. courses that will remind calm. And of course I have a bunch of courses and will continue to publish courses on pluralsight.com.
Tim Bourguignon 39:42
Well, Sean, thank you very much. It is been a pleasure listening to your story and get all those advices absolutely awesome. content. Thank you very much for that.
Shawn Wildermuth 39:55
Thank you so much for having me on. This has been a blast. Anyone who's seen the Talk at a conference or taking one of my courses will know how much I enjoy the sound of my own voice. So this has been a pleasure.
Tim Bourguignon 40:07
And this has been another episode of developer's journey. We'll see each other in two weeks. Bye.
Dear listener, if you haven't subscribed yet, you can find this podcast in iTunes, Google music, Stitcher, Spotify, and much more. Head over to WWE WWF journey dot info to read the shownotes find all the links mentioned during the episode. And of course, links to the podcast on all these platforms. Don't miss the next developer's journey story by subscribing to the podcast with the app of your choice right now. If you like what we do, please rate the podcast, write a comment on those platforms, and promote the podcast and social media. This really helps fellow developers discover the podcast and do fantastic journeys. Thank you