« All Episodes

Interview with Dave Rael (Part 1)

Published 10/24/2016

In today's episode, I talk with Dave Rael, host of Developer On Fire.

Today's episode mentions quite a few of the episodes on Dave's show, so make sure you go and check it out! All of the mentioned episodes can be found at the following link.

Today's sponsor is Chartio. All of your data in one place. Simply powerful. Start your free trial today at Spec.fm/chartio

Transcript (Generated by OpenAI Whisper)
Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell. In today's episode, I'm interviewing Dave Rael. Dave is the host of developer on fire. And Dave's podcast has been around since June of 2015. So go back and check out the catalog of episodes that Dave has recorded in the past, including episode 64. Dave was kind enough to invite me on to his show and I'm very happy to have him on Developer Tea today. If you've been listening to Developer Tea in the past week or so, then you know that we're kind of breaking from our schedule, talking about the developer career roadmap. I wanted to give you guys kind of a mental break to digest some of those steps and provide you with some more casual discussion between two developers slash podcasters that are interested in helping you out. So go and check out Dave's show and of course stay tuned to Developer Tea. Go ahead and subscribe to both shows that way you don't miss out on future episodes. Of course, we will pick back up with the developer career roadmap after our discussion with Dave. Let's get to the interview with developer on fire's Dave Rael. Welcome to the show Dave. Thank you very much Jonathan. I'm glad to be here. It's been quite a while since since you were on developer on fire and I'm looking forward to chatting again. Yeah, it was actually exactly 110 episodes ago and you were you told me just before we actually started rolling that that you're doing two episodes a week now with incredible names in your in your list of people that you've interviewed. So I'm humbled to be on that list first of all. But secondly, that's that's I think 55 weeks or just over two or I'm sorry, just over one year or so since we last spoke. That's about right. Yeah, I hadn't really thought about exactly how long it had been but yeah, it's been a long time. You know, when you when you mention being humbled to be on that list, I mean, I'm humbled as well to just get the chance to speak to so many awesome people and I've had quite a few people kind of respond to me when I've reached out to say, hey, do you want to be on the podcast? It's like, you know, I'm not worthy. I'm not of the caliber of a lot of your guests and I'm like, well, you know, I neither am I. So, you know, it's yeah, it's really I've talked to some absolutely astounding people. You know, that's a really good point actually for Developer To understand the people that you look up to. This is this is a still a relatively small injury. It's not a small industry, but it's small enough that the people you look up to, they aren't superstars like to the whole world. Yeah. Most people haven't really necessarily heard of these people. So, in other words, they're they're likely more accessible than you may think they are. Yeah. Yeah. It's kind of funny that I mean, even even the likes of David Hanemire Hanson, who is my most downloaded episode so far, you know, he's well known outside of software. And even his name, you know, a lot of people don't know who that is, you know, so it's the celebrities that we see, you know, they're not celebrities elsewhere. An Uncle Bob Martin, right? I mean, nobody outside of software is really, you know, that's not a household name. Except for, except for with us geeks. Yeah. Exactly. It's it is a funny thing because for me, it's a household name because myself and my father-in-law actually, he knows a lot of these names as well. So, there is kind of this like hall of fame feeling when I see those names. But really, most of these people they have email addresses just like you and I do and they check them just like you and I do probably too early in the day, just like you and I do. And they're trying to, you know, they're trying to stay up with the trends. They're trying to learn just like you and I are. Absolutely. Now they may be learning something different, some different material than I'm learning today. But every developer really is kind of cut from the same mold in the sense that we're all, you know, none of us are really superhuman. Some people have a little bit more brain capacity than the next person, but ultimately we're all pretty much the same. Yeah, definitely. And I think that's one of the big lessons that I've taken away from this podcast, this getting engaged and getting involved in the community is that, yeah, you know, these guys are human like every one of us. And, you know, a guy like Mark Seaman, who's a Danish programmer who I've looked up to, you know, and read his books and, you know, followed his blog and his material for a long time. And he's become, you know, one of my biggest fans, right? You know, I mean, he tweeted here a few weeks ago and after I had released episode 170, you know, he tweeted, you know, episode or achievement unlocked, you know, I've listened to all 170 episodes of developer on fire. And, you know, it's for somebody like that that I, you know, I've always considered to be, you know, one of the pillars of the community to respond to my stuff that way. It really, it gives me a feeling of that I am really contributing something and it's a great feeling. Yeah, we're going to talk a lot more about podcasting in this episode. And by the way, if you got, if people are familiar with Developer Tea, you know, that most likely this interview will go into two episodes. So go ahead and be prepared for this interview to span across two parts. But, and we may end up talking about podcasting a little bit more in part to you than we do in part one. But we just now kind of touched on a subject that I think is relevant to the first question that I have in my kind of unofficial list of questions here for you, Dave. And that is, you know, the type of advice that you have for people because you've talked to so many of these really more advanced people in their careers, right? You talk to people and interview them because they have, they've experienced some kind of success as a developer. And in general, that's probably the average person on your list. They've been relatively successful. And I really want to kind of ask you for that opposite end of the spectrum, the beginning of that process, you know, learning from these people, what could you tell a beginner about, you know, that long journey from where they are today to, you know, maybe actually landing on that list? Well, you know, I've had obviously a lot of experienced people like you said. I've had a few newer programmers. I had a guy named Dan Dalrymple on the show who he calls himself the history coder. And he blogs about his experiences as a history professor learning to code. And so, you know, I've had some of those kind of newer coders as well. Alex Squartney was another one who, you know, is kind of in the process of learning things. I'd say my advice is, you know, podcasts are wonderful, right? You know, to be a little bit self-serving, right? You know, subscribe and listen to some of these stories of people who have been there and have, you know, have experienced that. I had Doc Norton on the show, Michael Doc Norton. He really emphasized two mentors, right? You know, if you are working at a job and you've got somebody who, you know, is willing to kind of take you under their wing and show you the ropes and, you know, a pair program and do those things with you, soak that up, right? You know, having that first-hand experience of somebody who's willing to go the extra mile to help you, that is a beautiful thing. And don't miss that chance. It's another thing that I'd say. I guess beyond that, get involved, right? I think the mistake that I made early in my career was, you know, I was, you know, I was a young man learning to program and, you know, young men have a lot of priorities beyond, you know, just their career. And so, you know, I was caught up in, you know, late nights at the bar and, you know, all of those kinds of things. And I think, you know, rather than really focusing in my career, right? I wasn't really ambitious at that point. And I think if you start out early on and you get engaged, go to local user groups and not only attend, but, you know, maybe give a talk, right? You are learning something and it's probably something that somebody else wants to learn as well. Why not share that? And so, I think, you know, that's a great way to learn is to get up in front of people and find out what you don't know so that you can know what it is that you need to know. So, you know, that, that I did not engage more and that, you know, I was fearful really for a major, major part of my career and that, you know, I sat in the back of the room and I was, I was the developer stereotype, right? You know, the person who did not get involved, the person who, you know, I told myself I was actually recently interviewed by Jon Sunmez for the simple programmer podcast and website YouTube channel. And one of the things that I said on that interview that really resonated with people that got some tweets was that, you know, I, I told myself this story for a majority of my career that I'm good at machines, but not very good at humans. And that was the thing that really limited me. So, I think that's probably my number one advice is, you know, for one, you're better with humans than you think you are. And so, you know, just get engaged and two, you know, work on that, practice it. Yeah, let me extend that statement even further, you know, you say that you're good with machines, but not good with humans. Well, machines only exist as a result of humans existing in the first of the voice. Right? They're an extension of what we are doing in the earth. And, you know, not to be metaphysical about it or anything like that, but machines really are an extension of the human knowledge that we have. I was actually taught this in school that technology is actually, like the formal definition of technology is knowledge embedded. Right? So, taking knowledge and putting it in something else to hold on to and to operate on. Right? So, technology is really just knowledge embedded. The same thing is true with machines. So, to really get a good intuition about how to be, you know, as you said, good with machines, you really do have to have an intuition about how to be good with humans. Absolutely. Yeah. And machines are only useful to the extent that they serve humans anyway. And, you know, if you're really missing something, if you don't have some kind of feel for what the user of your application is and the, you know, the people all around that user. And so, yeah, it's of utmost importance that you really understand humans. Yeah. And totally agree with that. You know, I'm doing this series right now on Developer Teacalled the developer career roadmap. I don't know if you've had a chance to listen to it, but one of the things that I've mentioned on, it was actually the last episode that aired on the developer career roadmap when this episode will have aired. I'm trying to think forward in my mind here. Time shifting is over. Yeah. Yeah. So, the last episode that aired, I discussed the fact that there's, if there's anything that is of utmost 100% absolute importance, it is learning, right? And we talk about learning on Developer Teaall the time. My guess is in pretty much every episode that you have these incredible programmers on your show that you talk about learning quite often. Oh, yeah. Because learning is really kind of a core thing in our, in our field. It's, you know, you learn something new every single day that you touch code. And if you didn't, then you're probably not going to be valuable for very long, right? You have to learn more to be able to advance in your career. And we aren't just talking about learning new languages or, you know, learning new ways of doing things, really getting more of an intuition for the things that you already know even. That kind of learning is valuable too. So, you mentioned something though about having a mentor. The amazing thing, and the mentor step is actually later on in the developer career roadmap, right? That is to become a mentor, right? The interesting thing that happens when you actually take the time to, as you said, present to a local user group and get involved with a community, you have the opportunity to take knowledge that you know. And we were just talking about how technology is embedded knowledge. You can take knowledge you know and teach it to another person. Now, here's the amazing thing about that. Teaching is not giving someone else something so that you no longer have it. It is actually multiplying the value of the knowledge that you have. Yeah, yeah, just like downloading a file on the internet, right? I mean, you are just making a copy of that thing that that you now have that somebody else also now has and it is, you know, a freely shareable format and learning is exactly the same thing. And the amazing thing that happens when you teach is that you actually learn more. Yes. This is something that I believe really fundamentally. I don't really know something well until I have taught it to another person. Absolutely. Teaching is what really shows you those things that you don't understand, right? It exposes your holes. And there's really nothing like really trying to articulate. Here is what it is that I know that is useful to you. And then you've got to face the questions and the questions that somebody else has. That's where you find out. Do you really understand the thing? Today's episode is sponsored by Chartio, simply powerful. Chartio makes analyzing metrics and building reporting easy for both developers and for business users. And it frees up your time as a developer to work on things that will move the business forward instead of focusing on repetitive problems that require a developer's mind to solve with other platforms. Chartio connects to your live databases ensuring that you're reporting it as timely and it's accurate. You can blend data from multiple data sources into a single analysis or chart without a data warehouse. Use Chartio's data pipeline to create powerful Excel-like analysis against your live data. Chartio helps organizations bring full data transparency to everyone and it helps to improve company decision-making, strategy and performance. All of these things are things you should be thinking about as a great developer. Go and check it out for a free trial at spec.fm slash chartio. That's spec.fm slash cha rt.io. Thank you again to Chartio for sponsoring today's episode of Developer Tea. So let's take a step back. Maybe take a step down. A lot of people at this point, you've heard a lot from Developer Teaor you've heard a lot from developer on fire. And I'm going to actually kind of dive down into the details for a second. I want to ask you, what are some of the technologies that you are interested in right now? We don't really talk about that stuff a ton on this show because I like to talk a little bit more broadly. But I'd love to know what are some of the things that you're interested in now? Some things that are exciting you. Well, yeah, you know, it's developer on fire is very much the same, right? I want to talk about the humans that are programmers and learn about stories and technology intersects that and it doesn't it doesn't always, right? You know, there's there's a lot of ways that we can talk about developer careers and experiences without going into the details. So, but you know, my the majority of my career, I have been a.net developer. So, you know, I've C sharp has been my primary lingua, Frank, you know, for as long as I've been programming and it remains my primary. You know, the world has has moved on and, you know, everybody everybody has to know JavaScript now, right? So, you know, working with with node is something that's interesting to me now. I think there are there are other places that I that I would rather be the node most of the time, but node is great. I mean, it's got, you know, it's got that same thing as PHP where you can run it anywhere and you know, it doesn't matter about the platform and I think that is that's the beautiful thing about PHP and with JavaScript, you've got that as well. And then when you know, when you take into account the browser too. So, you know, I mean, JavaScript is exciting. It's, you know, I mean, I go back far enough to remember when, well, you know, if you want to do something snazzy in the browser, it had to be JavaScript and I would begrudgingly, you know, write this this language that I didn't understand and would just figure out enough to just make it work and, you know, be glad I was done with that and move on to some some server side code, right? But that's not the world we live in anymore and and JavaScript is exciting and it's it's once you, you know, once I stopped trying to turn it into Java, you know, it starts trying to trade it like Java, it became a really nice language to work with and so, you know, it's really one of those things that, you know, if you use it right, then, then there you go. I'm excited to about functional programming, though I still haven't gotten it yet, right? I still haven't had that moment of bliss where it's, you know, the, you know, I'm jealous of the people who have taken the plunge and have, you know, kind of gotten religion about it, but I haven't gotten there yet. So I'm trying and I think I think I will get there and I think I do see some of the some of the virtue, but I've still not yet, it still doesn't feel like home yet to me. So, you know, those are some things that are interesting to me at the time. Yeah, yeah, I pretty much most of your list I could probably duplicate. I've never done anything in.NET. That's where we probably are the most different, but the very first programming language I was ever even exposed to, by the way, was JavaScript, because I was a, I thought I was a designer at the time. Yeah, you came from, you remember talking about that. Yeah, yeah. So I came from design and I had built a website and I wanted it to do things, right? So I learned a little bit of J query. I'm sure if I were to go back and look at that code, I would be surprised at how awful it was. But yeah, everybody had that experience. Oh, yeah, sure, sure. And even a year ago, if I were to look at my code, I'm sure it would horrifying me. So that was the first time that I was exposed to to any kind of programming, any kind of thinking and code really. And it was an exciting process for me because I really had to start thinking in new ways about things. I didn't even understand the DOM fully when I started learning JavaScript. So that kind of launched me into my career of web development. But that was well before Node actually was even useful at that at that juncture. And I realized that JavaScript was powerful, but only in this limited arena. And I ended up moving on to PHP and a list of other languages. But I also am very excited about the future of JavaScript now. I'm very excited strangely about the future of PHP. I think the community around PHP is actually a really strong community and it's growing in many ways. So that's kind of an unpopular opinion in the web development world at this point. But I've been writing some PHP recently that I've really enjoyed writing. Well, there are fantastic people who are working with PHP and WordPress makes the internet go. So it's here to stay like it or not. For better or worse. I can remember reading some of Jeff Atwood's posts about how terrible PHP is and stuff like that. I've never really dug into it enough for me to say yes or no, it is as bad as people say it is. So I can't intelligently say that. I'm sure that obviously it's useful. And that's already there on just about any platform you're going to be on. That in and of itself is value right from the start. Sure. It's kind of that theory versus practice discussion, right? Because I'm not enough of a computer scientist to be able to evaluate that the underlying engine that makes PHP run. I just really don't understand that stuff at this point in my career at least. I could probably learn it if I wanted to, but I really don't need to because most of my career at least right now is composed of building things. And if PHP can help me build something in an effective way without massively undermining the thing that I'm trying to do, well, it becomes useful. Sure. Yeah. So not theoretically, but practically, it's a useful tool to me. Yeah. And it's no big licensing costs and you can deploy it to a digital ocean machine for very little amount of money and have something up and running. And there's a lot to be said for that. Yeah, absolutely. So this is one of the only times that you'll hear the two theoretical guys who are talking about your career in larger, broader terms talk about specific technology. So that was a little bit of fun. I haven't done that in quite a while. Actually, awesome. Dave, I'd love to kind of shift gears here and talk about podcasting a little bit more, maybe talk a little bit about the process of publishing and what you have learned as a result of publishing regularly. I think we talked about the idea of committing to a publishing schedule when I was on your show. And I'd love to talk to you about how that has taught you things. I know how it has changed the way I look at my career. But I'd love to hear from you. What are some of the things that podcasting has taught you? Not just about the publishing world, but also that information applied to your development career. Well, I think having a committed schedule is something that when you have some feature to implement when you're writing code, it depends on the environment. A lot of times there are artificially imposed schedules in some of those things. So you're trying to meet a date. There's a lot of that kind of stuff. But when it's imposed by somebody else, it always feels artificial and it feels a little, depending on the environment. There are places where you have a saying you can give estimates. And those estimates are honored. Most of the places that I've worked in my career when you make an estimate, it's well, can we bring it in closer than that? And pretty soon, they're trying to talk you out of the estimate that you gave and try to meet some unrealistic schedule that requires compromising on a lot of quality and a lot of those kinds of things. And so trying to meet dates, I don't know, I have a love-hate relationship with that. But with the podcast schedule, it's something that I've decided on my own. Well, that's not completely true. In the beginning, it was when there was no audience. I decided what I was going to do. I started with doing two episodes a week. And I increased it to three because I thought it was great. And I was able to stick to that schedule. And then listeners started telling me on Twitter and emails and some things that it was too much. And they couldn't listen to that much. Ultimately, the listeners told me that two was the right number. And so I went down to that. But it really is, it's something that I had a hand in. And I was able to pick. And so I think that there's a lot of value in that. That you are serving your audience. You are serving your user, your customer, at the same time. It's a given take. You are giving something that is a sustainable pace and some of those things. So I think to me, it's kind of a big shift from a lot of the dysfunction that there is in the corporate world as far as trying to plan for dates and things like that. And getting into some agile process kind of things with sprint schedules and some of those things, I think that went a long way toward fixing some of those problems of the calendar driven development. And having, so you're putting things into an iteration. And I think I guess I would liken that to having a publishing schedule for the podcast. There's something that's going to go out. And it's going to be ready to go out. And podcasting is a little different because, you know, there's not really going to be a cutting of scope, right? I mean, it's really pretty much the same thing every time. So there are some parallels and there are some things that are not parallel. Podcasting is, it's a lot more reliable, right? That, that, you know, the estimate that I give for how long it's going to take to edit and write show notes and that kind of stuff. Well, the editing can vary quite a bit actually depending on the guest and, you know, a lot of things can happen that require editing and some of them are just a snap, right? You know, it's, it's pretty much just, you know, just get it out there. But yeah, I kind of feel like I'm rambling a little bit. But, you know, I think that it's pretty predictable. And so, you know, that's, that's different from software because, you know, I mean, Hofstetter's law applies in software. I think more than anywhere in life, you know, that states that it always takes longer than you think it will, even when you take into account Hofstetter's law. So, you know, that, it's really, you know, podcasting, I think, is simpler in that respect because you know what you're going to get for the most part. Man, there's so many things that you just said that resound with me as a podcaster in the, in the similar space. First of all, your actual, your episode schedule mirrors mine. I started out doing three and, and I really enjoyed it. I actually started, I tried to do four, four per week. And people started tweeting. I mean, they didn't tell me that it was too much because the episodes are relatively short. Instead, they said your, your quality is kind of suffering, which is, which is kind of a, a really like, it's a very frustrating thing to hear as a podcaster, right? Because you, you, you pride yourself on the audio quality. Hopefully things are coming out on the other end, correctly. And, and, and people will, at the very least, they're going to only put you over the burner for the content. So, that, because the quality is something that you feel like, well, of course, I have control over that, right? But, in fact, I was spreading myself too thin. And I was, you know, I was, I was basically just reaching too far. And I ended up backing back down to three episodes a week. So that was, that's a very interesting parallel that we have there, where you experience something similar. I'll be at yours backing down for a different reason. Yeah, but you know, listening to the audience, I think is the key point there. And, and you know, that, that has some very serious parallels to software, you know, that, right? Getting that feedback is of critical importance. Well, it's also proof that we tend to overestimate our capabilities. Yeah. And we get really excited about something. We have a lot of energy to put into something, whether that's a podcast or a programming project or even just a friendship, right? In our normal everyday lives, we overestimate our ability to, to pour energy into something even if we care about it a lot. Yeah, for sure. So as a result of that, you know, I've learned that, like you said, podcasting has a little bit more predictability. You're not doing something that you've never done before. You're basically doing something that you've done quite a few more times. You know, I actually just noticed, by the way, that this episode is episode 301. So we've, I've been doing this enough now that I know kind of the feeling about the pace that I should go. Yeah. Yeah. You know, it's interesting too when you talk about quality, right? You were talking about the quality of the content, but you know, then there's also the audio quality too, right? And, you know, you talk about, you know, hitting the 300 episodes and, you know, knowing what you're doing and you mentioned looking at your code that you wrote a year ago and being horrified, well, you know, the same thing with the podcast, right? You know, I look at back some of my, some of my early episodes and, you know, who was that guy? Right? You know, who was that stumbling, bubbling guy that had such a hard time with it? But, you know, after all this time and, you know, feeling like I have become, you know, a professional at being a podcaster, you know, I had a misconfiguration on my computer and for a few episodes, I recorded the wrong microphone and I had, you know, the audio quality suffered and it was really bad. And, you know, I thought about asking these guests, hey, could we do a doover on this and do it again? You know, one that comes to mind was Anthony Shaw, but when I listened to the audio and he shared some things about the anxiety that he's felt and it was just so heartfelt and it was so just wonderful that I mean, you know, it wouldn't be the same to try to have that conversation again, right? And so I went ahead and published it with the degraded audio quality and it's still, you know, I mean, it got rave reviews and Anthony was absolutely spectacular. But, you know, making those kinds of rookie mistakes after, you know, after doing hundreds of episodes, you know, it's embarrassing, but, you know, it happens, you know, it's one of those unexpected things that happens just like in software, you know, but, you know, it's, I don't know what I'm trying to say, but you know, those things happen and, you know, you make mistakes no matter who you are. Absolutely. I mean, this is the kind of thing, you know, if you do it even 100, 200, 300 times, there's still something to be learned and that lesson is probably one of the biggest ones I've taken away from this constant publishing schedule that I have that I've committed to. There's always something new to be learned and that's something that I want to bring to my development career. It's something that I want to teach the Developer That I lead on a daily basis. I want to help other people realize that there is, there isn't really an end to the road. This is a journey that will continue on, you know, throughout the remainder of your career as long as you want to continue it. Yes, yeah, always more to learn. Thank you so much for listening to today's episode of Developer Tea, the first part of my interview with David Rael. If you've been listening to Developer Tea for a while, you know that we kind of took a short hiatus from the developer career roadmap. Don't worry, we will get right back to the developer career roadmap after the second part of my interview with David Rael. Thank you again to today's sponsor, Chartio. Chartio makes analyzing metrics and building reporting easy for both developers and business users. Go and check it out, spec.fm slash Chartio and get started with your free trial. That's open to all spec.fm listeners. Go and check it out again, spec.fm slash Chartio. Thank you again for listening to Developer Tea. If you don't want to miss out on future episodes, make sure you subscribe and whatever podcasting app you use and until next time, enjoy your tea.