DevJourney Logo

DevJourney Podcast

#112 Dan Moore went from sci-fi to devrel

Transcript

The following transcript was automatically generated.
Help us out, Submit a pull-request to correct potential mistakes

Dan Moore 0:00
Yeah, sure we're gonna, we're gonna help you build a Yahoo clone. And the lead developer fell sick. We were using a bunch of new given different technologies. And I, you know, looked around and no one else was there to step up. And so I stepped up and I worked create what I consider crazy hours, certainly the craziest in my career. I think I clocked it one week, I worked 96 hours. And as you can imagine, I wasn't super effective. But I mean, I got it done. And they they gave me we had a we had a launch party, and I'll give you a little quiz here. What do you think they gave me in terms of thanks? Do you think they gave me a like a $5,000 bonus? Do you think they gave me a nice dinner out or you think they gave me a six pack of beer and a T shirt?

Tim Bourguignon 0:54
Hello and welcome to developer's journey, the podcast bringing you the making of stories of successful software developers to help you on your upcoming journey. My name is Tim Bourguignon, and today I receive Dan Moore. Dan has tasted most of what our industry has to offer, large and small companies, startups, individual contribution, management, communities, writing and much more. But I'll stop right there because he's about to tell us his story in a minute. Dan, welcome to DevJourney.

Dan Moore 1:24
Oh, thanks for having me.

Tim Bourguignon 1:25
This show exists to help the listeners understand what your story looked like and imagine how to shape their own future. So let's go back to your beginning, shall we? Where would you place the start, the beginning, of your developer's journey?

Dan Moore 1:41
Two words for you: mail merge. So my parents had an Insurance Brokerage when I was growing up. And one of the things that we had to do was notify people when their insurance policy was due, right because they expire every year. And legally, we had to do this. The first couple of times that I was involved, basically, we were cutting and pasting a bunch of Word documents, it was actually WordPerfect back in the 90s, a bunch of WordPerfect documents over and over again. And I had played around a little bit with Logo in my elementary school days. But I said, There's gotta be a better way to do this. And so I ended up building a little database, and doing MailMerge to generate all of these documents that were legally required. And, you know, it was the most fun I had, it was a lot more fun than stuffing envelopes or doing cut and paste. And it really showed me the power of software, even relatively simple software to reduce toil and reduce human misery, even in this very small sphere. And that hooked me and that was where I would place the start of my developer's journey.

Tim Bourguignon 2:52
I guess that's the first time I hear the words "mailmerge" and "fun" used in the same sentence. Okay, I see your point. Mail Merge is, is a pain in the ass, but not having mail merge and having to do a per hand is even worse. So I'm with you on that one. And I'm still trying to do some mail merge with, with MS Word sometimes and what doesn't work, it just doesn't work.

Dan Moore 3:21
It's gonna be around for about 1000 years I expect as long as we're sending mail sure...

Tim Bourguignon 3:28
That is true. That is true. But you said you've been doing some Logo programming before so that was in in junior high school or high school. What was it? How did you come to programming?

Dan Moore 3:39
It must have been in elementary school. Are you familiar with logo? It's like a turtle and like drawing pictures? So I mean, basically it was like drawing a star drawing triangles like just playing around with it with a computer. I was lucky to have access to computers pretty early in my life.

Tim Bourguignon 3:57
Okay, but that was kind of part of your curriculum?

Dan Moore 4:00
Gosh, I think yeah, I think we had like a special like, it was like Gym was one day and then like going to computer lab was another day where you would just get like go there and in third grade or whatnot and play around with it. Yeah.

Tim Bourguignon 4:14
Okay, and then you had a computer at home?

Dan Moore 4:16
Yeah, I definitely remember having one around fifth grade. I don't know if you have one before then. But that's where I learned about WordPerfect and macros and, and all that fun word processing stuff. Now, how did you get into that? I get into it. I honestly don't remember. It probably was. I mean, I definitely remember having to write some reports. And that was probably how I got into it. And then we're perfect had this thing where you could like shift modes, right? So this was back in kind of dos. And so you would actually there was like a way where it was kind of it was maybe what you see is what you get, but then there was a Another way we could see the code, so there's like a, you know, tag almost like HTML tags for around bold stuff and like italicize stuff. And that was just fun to switch back and forth. And then that led to like, macros, which were kind of recording of, of bits of text. So you wouldn't have to type a whole thing, you could just type a couple letters. And that led me on to just kind of understand the basics of the word processor at that point.

Tim Bourguignon 5:26
So at what point did you have the feeling that you were going from the from the user perspective, to the creator perspective?

Dan Moore 5:34
I mean, I think when I showed my, my parents the database, and they're like, holy cow, right. And that was really empowering for me, because I was, I think it was maybe an eighth grade, ninth grade. And, you know, at that age, you can't really do a lot that your parents can't do, but this definitely felt like something that they'd never thought about doing. They weren't really I mean, they use computers for word processing accounting, but they had never I thought about creating a database. And so that was probably the moment when I was like, wow, you know, programming is, you know, or I don't even know what I thought of as actual programming, but like, this was pretty cool to be able to do this.

Tim Bourguignon 6:11
Did you have any idea back then that this could become your future?

Dan Moore 6:15
You know, honestly, I don't think so. Skipping ahead few years, when I was going to college actually picked a college based on wanting to be a writer. And like a science fiction writer, and I don't think that I ever thought that software engineering would be a 20 year career for me.

Tim Bourguignon 6:39
So how did you go from science fiction writing to to science fiction programming? I had an internship after my freshman year of college, where I was working with a family friend who was in charge of some software, the software Department of Public Schools system and so we were actually putting stuff on disks and sending stuff out to teachers and other members of the community who wanted to dial up and dial into the modems and use Netscape Navigator and we were doing some of that and then also there was like some they had a Solaris box or CentOS actually was before Solaris CentOS box and there were some log files that he wanted me to parse. He tells the story to my parents which kind of makes me blush a little bit but he said he you know, he gave me this task expecting me to take it you know, about a month or a couple of months and keep me busy throughout my internship and then I you know, I read the Perl book because I was using Perl, probably for the Parsing, logs file log files, and I came back in a week just eager for more and you know, again, probably eager for more. "Perl" and "eager for more" have never been used in the same sentence either in your podcast. But then I started to do, I stayed in, I did an internship my sophomore year. And that was like a pure physics internship where I was working with a professor of my school. And it was very experimental. And I just realized how much fun I wasn't having, you know, experimentation labs were never really something I enjoyed. And so I end up getting a job as a proctor at the computer, the computer lab in college, and I wrote some stuff there. And then I got another internship where I was kind of combining physics and writing software writing applets, for visualization of physics to help with education. And then I ended up doing a senior thesis. That was, again, it was supposed to be a physics problem, but it really was like a distributed computational problem that I was working with Java and remote, remote, something interface RM Whatever that is, that lets you kind of communicate between different Java processes running on different computers. And that point, I was like, Wow, that's really, really, uh, you know, this is something that I'm enjoying is something I'm fairly good at. And then I end up getting a internship after college in back in my home state. And, you know, that was at a small consulting company, and that was after that it was kind of off to the races. So that was kind of like when I knew that that software element was, you know, lucrative. I'm not gonna pretend I'm not attracted to the the money, but it's also really intellectually stimulating. People care about you and employ, you know, I found that most people care about employees in a way that doesn't necessarily happen to other professions. And then, you know, the biggest thing to me is that there's always something new to learn. So, that those are kind of the reasons why I, you know, took those steps. So if I got this right, you kind of fought against it. It was there in your life already. And you went in a different way in college and you had some internships that were hinting it this way again, and you didn't choose it. And then in sophomore years again, and only in your senior year is you were you really deep dived into Java and processes and it really started to smell a lot like computer sciences. And then in your next internship, that was that. Did I get that right?

Dan Moore 10:28
I mean fight against it might be a little bit of a strong term. I mean, I guess I would say that I explore other options, but you know how it is when? Or maybe this isn't, I mean, you've talked to a lot more people about their journeys than I have. You know, I think that there are things that are there things I try to do that are against the grain that even if I know I need to be good at them. It takes like a lot of practice. And then there are things that I do that are kind of with migraine and software development. It just turned out to be one of those things in physics wasn't right. I mean, I really enjoyed the first couple years of physics. And then after we got into some of the, either the more lab heavy stuff, or the stuff that was a little more esoteric that I just, I just didn't see myself being a professor. I didn't see myself being a researcher and that are, it's hard to find a job in physics, if you're not willing to do one of those two things.

Tim Bourguignon 11:23
So it is true. Yeah. Okay. So how did you go and get your first job in? In in it?

Dan Moore 11:31
Yeah, so I actually, and this is something that I think I hope we can come back to but the power of like, networks and not like software network, sorry, like people networks is so important to me in my career, and I've seen it be important other people's careers. So I did that internship where I was, you know, doing using Perl to parse log files and helping people install Netscape Navigator and that person's name was Dave De Bain, and he had worked with a consulting company up in Boulder, Colorado. And so when I was looking for a job, I asked Dave, you know, hey, do you know anybody who's looking to hire software developers and he introduced me to that consulting company, which was called XOR, which was super formative. And I can talk more about like, the ways it was formative for me and how it's still that experience those three years there has really reverberate throughout my career. But they, I talked to the director of engineering there, I remember because it was kind of may and they actually helped support the website for the Kentucky Derby at the time. And so he was he was a little bit preoccupied, a little bit busy, but he found time to chat with me. And he hired me as an intern for $10 an hour. And so I was there. I moved back to Colorado and I moved into a place up in Boulder and Was there and three weeks in, he's he pulled me as an office and says, Hey, and said, Hey, Dan, do you want a full time job and put it through on a number $42,000 that was bigger than I had ever, you know, thought because I was used to working these $10 $12 hour jobs in late 90s. And so I said, heck, yeah. Right, because it wasn't just the money again, it was the team that I was with. It was the problems we were solving. I was learning something every day. And this was in 99. So kind of.com craziness. And so you know, we had something fun. Every Friday, I was going out with a set of people and like building a real like set of friendships. And the coding was fun, too. So yeah, yeah.

Tim Bourguignon 13:46
Let's talk about it. You said those were three very formative years. In which way?

Dan Moore 13:53
Yeah, so I think they were formative and in good and bad ways, right? Because I think both kinds of experiences can really help you I definitely saw how teams could work together to accomplish things. I definitely saw how executives can come in and give me a little bit of cynicism around executives. Although as I've gotten further along in my career, I have more compassion for the choices they were faced with, right. I mean, in in 99, they were talking about opening offices, it was a five or 600 person company in 99. They were talking about opening offices in London, in Singapore. And in 2001, they were laying people off, right, so they had to make some hard choices. One lesson that really, you know, that I talked about all the time, is, there was a situation where when I was on a small team, couple of developers we were delivering for a client because it was a consulting company, right? So very project based work, we'd sell something and then we would staff it up and then we would build the thing and Send it off. And then they would they typically they would operate over. We tried to help them operate it. And they came in and they wanted to build a Yahoo clone. And this was back when Yahoo was was sexy and exciting. And so we said, Yeah, sure, we're gonna, we're gonna help you build the Yahoo clone. And the lead developer fell sick. We were using a bunch of new given different technologies. And I, you know, looked around and no one else was there to step up. And so I stepped up and I worked create what I consider crazy hours, certainly the craziest in my career. I think I clocked it one week, I worked 96 hours. And as you can imagine, I wasn't super effective. But I mean, I got it done. And they they gave me we had a we had a launch party, and I'll give you a little quiz here. What do you think they gave me in terms of things do you think they gave me like a $5,000 bonus? Do you think they gave me a nice dinner out? Do you think gave me a six pack of beer and a T shirt.

Tim Bourguignon 16:02
Go for the latest.

Dan Moore 16:03
Yep. In and that has drove home to me like, I save them. I don't know what would happen if we default on our contract. But in my mind, at least I really kind of push the boundaries of my health and, you know, certainly my expertise to deliver this project. And they basically, you know, said, Well, here you are, you know, thanks. But, you know, they give me a token, right. And that just taught me that a company is never going to value your time as much as you do. And there's nothing wrong with putting in a hard day's work and there's nothing wrong with working more than then you might be expected to but don't expect anything from the company. Like just do it because you want to do it because you feel you need to. But don't don't expect anything in the company. Did you have this experience again in subsequent companies human. So I yeah, so I have done since then. I I've worked at some consulting shops and some startups. I think that startup is kind of a different category because they're your, you know, you're an owner. And even then I don't think I ever hit 90 hours a week. And can recent consulting company, there were a couple of weeks where I worked 60 or 70. But I was director of engineering, I did that with my eyes wide open. I said, You know, I know that the, you know, what I can expect is like a thank you. And I'm not expecting anything else. I think that's the biggest lesson is just, it's better to set expectations for yourself, and then you're less likely to be disappointed. And that was probably the biggest thing as I was expecting to be treated more maybe like a hero and they didn't want to and, you know, now that I look back on it now, I say that they might have wanted to discourage that kind of behavior. Maybe that was the reason they did it. I don't know. Maybe they just didn't know about it. That's probably more likely. But I Don't think that long hours ever serve you unless you're building something that you own.

Tim Bourguignon 18:05
That's a very good point. I'm trying to, to imagine how I would react with my team, if somebody was was pulling very long hours like this, and maybe saving the day, but that's clearly not a behavior that I want to encourage. So how do you reward somebody for for going the extra mile and then and doing the work, but without making a precedence, of a positive precedent out of it? Yeah. I mean, it's one question.

Dan Moore 18:36
Yeah, I think I mean, I would hope that you certainly if I was an engineering manager role, I would. I mean, I've actually done this. I've actually told people Hey, stop working so much, right? Or do this if you want to, but realize these are the ramifications. And I kind of wish a manager pulled me aside and said, Hey, Dan, thanks for doing that. But really, you know, we can see that's wearing on you. We can see you're tired and and you're Life isn't, you know don't don't spend your life for this company. But that's kinda depressing. Now that I say that that.

Tim Bourguignon 19:09
lLife life stories and and learnings, that's quite often things you have to live through before you can really understand what it means...

Dan Moore 19:15
But I mean, so the plus side of being at XOR at that consoling company is that I have, I've gotten a number of jobs from people I've met there I have, you know, I'm still friends with people that I've met there. It was a real, not that particular 96 hour week thing, but the rest of the experience, the calm experience, the, you know, being exposed to very, a bunch of different technologies, Perl, Java, version, control docbook, all kinds of interesting things that maybe aren't as exciting now as they were in the early 2000s. We got it. I always recommend, if people don't know when when new developers talk to me if people don't know Know what they're going to do. I think small conservative consulting shops are great places to start, because you'll be exposed to a wide variety of business domains and technology domains. And you'll, if you get on a product you hate, you're going to be moved off it in not that long period of time. And because it's small, it's actually gonna like what you do actually matters, right? Like fact I did that night, it's our week actually mattered the company, as opposed to you go work for Deloitte. And they'll still want you to work with ours, but it doesn't. You don't have that quite visceral like feedback loop.

Tim Bourguignon 20:36
Definitely, definitely. You mentioned, that that's probably saw some kind of fast forward from me, but I'll do it anyway. You mentioned a position of Director of Engineering when we're talking about the engineering management. So how did you go from from a developer or an individual contributor to learning how to be a consultant and then dipping your toes into maybe team leading and then going to management then leave whole department and then going back to founding, how did you did you jump from one position to the other and learn how to do this?

Dan Moore 21:07
So your question is how did I learn how to be a manager? Or how do I learn how to transition between these different kinds of roles? The latest so how to learn to learn to how to transition and be a jack of all trade or be what you need to you need to be at that point. Sure. I mean, so I would say that both of the times I did management, I was an internal promotion. And so that I find is a lot simpler than going to be you know, being icy at one come a company a and moving to like Management Company B. So I've taken two swings, injury management, I'm not sure that I'm cut out to be an injury manager. Because both times I had pretty good support from above, and I had some time to think No read and some time to learn. I mean, I definitely, I think that I think I tweeted this recently that engineering management and being an engineer, a software engineer are about as similar as American football and regular football, right? Soccer. You know, there's goals in both ones. They're both played on a field. But and there's so there's overlap that they're definitely disparate skill sets, and I 100% respect the great engineering managers that I've interacted with, and you know, product managers and whatnot, but it's a whole different set of skills. And so I basically picked them up ad hoc. I will say that I unfortunately, in both those situations that I was an injury manager, the teams were small enough, and the companies were small enough that and this The downside for working for a small company, is that I had to be a player coach, and I feel like that doesn't give you as much time nor as much incentive in some ways to follow focus on getting really good at this new skill, right this people management skill, because you can still you still need to dip your hands back into code and like deliver code instead of really focusing on building up your team members. I feel like I'm, I'm wondering a little bit, I guess specifically, what steps I would take to learn a new role is, you know, reach out to people who are currently in that role, ask them questions, lean on them for guidance. Usually, you can find some great books, especially around something is well known as engineering management. I joined the Rand's leadership Slack, which is a there's a great author called Michael lop, who's written a blog called rands in repose. And he's basically built this group of over 10,000 engineering managers or former engineer managers in that span. When I was a manager's manager that was helpful to me because I could ask them technical questions.

Tim Bourguignon 24:02
You created your own company, right? How did that relate to being a manager? That's kind of the same skill set that we assume.

Dan Moore 24:10
It's actually I found it to be so so the company that you're referring to, I found it in 2016. It was called the food corridor. And fantastic experience. I was there for a couple of years. My co founder had the idea. And I was the engineer. And, you know, when I when you know, seats, when start when you're a startup, you can hand out titles like candy, right, like CTO is definitely like the default engineering title. But I actually wrote a blog post called founding engineer or founding CTO. And as you grow as a company, the CTO role becomes more and more like, what is what a real CTO does, right? The CTO of like a big company is really shouldn't be touching code very much at all. Maybe they're doing code reviews. or working on non critical features, but they are talking about strategy, they're really interfacing with the business they might be doing recruiting. What I was at the food core was really like a hands on CTO. And I was really a founding engineer. And if I'd stayed in the company, it's possible I could have grown to be the CTO. But, you know, when we first started company was two people with me and my co founder, right. And so I was, you know, she wasn't gonna write any code. She wasn't technical, she could give the UX feedback. And she ran user user interviews, and really was the domain expert, I was really responsible for kind of taking her product vision and implementing it. So I would say that being a startup CTO, especially about one or two or three person startup is really nothing. You know, you're not gonna use too many skills other than like, being able to talk to customers that you would if you were addressing engineering at their company.

Tim Bourguignon 25:59
Nice to see. Okay, thanks. Thanks for clarifying that. You worked for Oracle at some point, didn't you?

Dan Moore 26:07
So as a contractor, I should be care as a contractor.

Tim Bourguignon 26:11
Just shortly in a few sentences, how was it to work for such a giant company after all, in between, in between smaller, smaller or even tiny ones?

Dan Moore 26:21
It was weird, man. I mean, it's a different world, you know, in terms of, so there's like the bureaucracy side, and I'll try to keep this brief. You know, as, as far as I understand it, like I was just a contractor being hired, and the Office of the President of Oracle, Larry Ellison's office had to sign off on me being hired and that level of bureaucracy, bureaucratic control felt really weird. At the same time, the technical technology opportunities to work there. Were just, you know, leaps and bounds above what you get at a small company. They were the piece that I was working on was to Like, kind of reconciliation of offline and online advertising audiences, and just dealing with like tremendous volumes of data and traffic in a way that I just never I had never seen before. So that was really exciting piece. But the black sheep is slowly nuts.

Tim Bourguignon 27:20
I would tend to, to believe so that's exactly what I would expect. Okay, um, before and before times runs out, and we don't talk about it. I would like to segue into the book you're finishing or finished already. And could you could you give us the, the pitch for the book, and then the origin story and how it emerged and how you you got to writing this? Because I think that's, that's a really interesting story in there.

Dan Moore 27:50
Right? Yeah, sure. So essentially, the book is, this is a set of basically letters to developers that are already Organized by theme, and will be kind of bite sized bits of advice that you can read whenever you want, and will help you become a better developer, a better team member, a better developer, and better able to progress in your career. So that's kind of the pitch for it. And I had written a book about a particular technology, Apache Cordova in the early 2010s. And it was a 40 page ebook, and tremendous effort and super fun to written. And then we immediately stopped using that technology at my company. And I said, I'm never going to do that. Again. I really enjoy reading a book but I don't want to write a book about a technology because technologies unless you are, like immersed in them, and as you mentioned, I've kind of jumped across different technologies in my career, unless you're immersed in them, then the book either become somebody to maintain have like a passion or it just it just gets Old and doesn't doesn't do anybody any good. So I started looking around and see what was something that was evergreen, that would be interesting for me to write. And I had this theory that you shouldn't write a book unless you can write 10 great blog posts. And so I started a blog. And basically, I blogged for about a year and a half, before I even talked to anybody about possibly publishing the book. And basically, I was writing one to two posts a week, and sharing them around seeing where they're resonating. And it finally got to the point where I, I can talk to a publisher about it briefly. And I'd never worked with a book publisher, the previous book was self published. And people were like, at meetups, were saying, hey, Dan, thanks so much for your advice. And, you know, I sent I share this with other people, my blog, and that just really struck home to me that hey, you know, maybe this is worth spending the time and effort to actually turn into a real book? Yeah, that's kind of the origin story.

Tim Bourguignon 30:07
Can you give us some some examples of those letters of the topics you addressed the old squishy soft skills? Or do you go deep into some tech anyway? Or are you still normal in the architectural and and cross cutting concerns in of programming and stuff? Most should the listeners picture that?

Dan Moore 30:26
Great question. So it's primarily soft skills, which I think is a horrible name. I think that I find I find them pretty hard. And I know that some other developers too. I do jump into like some tooling where I feel it's it's evergreen. So stuff like version control systems. I'm not going to give you the the in depth of you know, partial file adding on yet or anything like that. I'm going to say you should learn a version control system because these are the things they will help you do. Or debugging or I talked a little bit Jq Aachen said Because I think those tools have been around for decades and will be around for decades more. But no, I mean things to my most popular posts are one is avoid working alone, where I talked about how if you are like, again, my audience is primarily newer developers, people that are five years experience. If you're kind of a new developer, and you get pulled into a company where you're one of, you know, a very few technical people, or possibly the only technical person, you're gonna have a way harder time progressing than if you go into a company that has a team of developers that you can learn from. That was one of my popular posts

Tim Bourguignon 31:40
That's an interesting one. Avoid working alone. If you can avoid it, then fantastic, then you have people around you, but what if you can't? What advice would you give to developers, maybe newer developers that find themselves in such such a context with not many people around them or people They cannot completely use us as mentors or as as stepping stones, what would you advise them?

Dan Moore 32:08
Yeah, it's a great question. Because you're right. Sometimes you just, especially in this in this job market, I don't know how it is in Europe, but like, there's a ton of people come junior developers, I call them new developers on the market. And sometimes you just have to take what you can get, right? And so in that case, I would hundred percent, do a couple things. One is I would keep your resume up to date. Because after you have a year of experience, you're going to find a much easier to find a different job. But I would also reach out to other communities, right. And we live in a world that is interconnected, so their online communities. You know, I can Hacker News is maybe not the friendliest one, but it's definitely out there. And there are other ones like that. And then there are online there are offline communities meetups, and again, this depends on where you live, right. There are definitely places that don't have great meetups. But if you can go to a local meetup, and especially if you go there multiple times, you can start to like, be integrated in the community. And that point, you can start to ask questions about, hey, we're doing it this way at my current company, is this kind of a bad idea. And, frankly, honestly, right now with with COVID most meetups online, so those are kind of the things I would do if I were a new developer right now and I was working alone.

Tim Bourguignon 33:34
Next to the to the comments you made at the beginning, we're talking about networking, and how important that is.

Dan Moore 33:40
Yeah, I mean, so just put some numbers on that. I think I did some. I think I've had eight or nine jobs in my career, like full time w two jobs. And I'd say half of them have been found through my network and I would say The older I get them, the more that happens. I'd also say that like my contracts, I think I've had 10 or 20. But I can serve me long term contracts. And 60 or 70% of those came through people I've worked with. So if I get one piece of advice to give to new developers, I'd say Don't look down your nose at LinkedIn. Because LinkedIn is a Rolodex. My friend says, this is a Rolodex, other people keep updated. And you can, you know, people interviewing is hard enough like, if you can get like a power up by interviewing someplace where somebody already knows you it's gonna make things so much better.

Tim Bourguignon 34:44
Huh? I totally agree. I was I was looking at some job offers on job postings on LinkedIn a couple days ago, and seeing there and they have they have a new a new system to to allow you to to apply directly. And there they have underestimation of how many people people apply to ready. And all the jobs I made this comparison and looking at the into this, the jobs that specifically post as Remote Jobs versus the non remote ones. And there's really a factor of 10 between the two of them. It's a 10 x. So the jobs that have a remote, remote flag, they get something like 200 300 plus applications in a couple days nowadays. So there's absolutely no chance for you to get in there without without a bit of networking. It's I'm really wondering how HR departments are going to handle this or companies trying to hire gonna handle this in the future when we're going more and more remote. Recently I heard from from Basecamp that they have multiple thousand applicants for each position they publish which is absolutely nuts.

Dan Moore 35:59
Yeah, I mean, how do you even like you can't give, you can't give everybody a fair shot, right? Like you have. So you have to, like, start to use these like the resume, like just like, throw the resumes into the trash pile as quickly as you can, right or like find any factor, because you throw them out, which is that's horrible for I mean, it's horrible for everybody. Right, but I don't answer it.

Tim Bourguignon 36:21
Yeah, I don't either. I'm sure. That was though that was the problem was thinking about was on while I was driving. How would How would I solve this problem? I have. I have absolutely no idea. Do from a from an applicant. perspective. Yeah, networking and trying to get there or trying to to show your work before you can. You can apply but applying directly for for position. I think it's it's, it's in the best.

Dan Moore 36:49
Yeah, I think that's a good way to put it is it and that may be the answer is like you're going to have to make it used to be that it was hard to apply for a job right because you had you know, back in the 80s You had to, like, find the job and like, like mail something in. And now it's very, very easy. And so and and the job boards have every incentive to make these right, because that's how they, they keep things going. But I think companies are gonna have to make it harder, right. And you can make it harder during the interview process and or you can make it harder before the interview process. But I guess then I would like to say is, I think that the important truth is the back channel networking, right? And you being able to hand your resume to somebody you were before, is great if you've had a chance to work with somebody before, but it really closes the door on a lot of talented people. And I don't, that's one of the reasons I started the blog is that I wanted to help new developers avoid mistakes I made and get better quicker, and I still want to help them. I don't know how to help them go into my network, except for it. Do let people like that I meet at a meetup, I say, hey, go and check me on LinkedIn and look at people that I'm connected to that are in companies that you're interested in. And I will be happy to do an intro for you. It won't be like, hey, I've worked with person ABC, and they're awesome. It'll be more like, Hey, I met this person that meetup they seemed cool. That's very least that's something that I can offer that like help try to break down that that network

Tim Bourguignon 38:23
when you can do that. That's for that's very, very helpful. But how would you maybe you you've done this before? How do you handle the the balance between pushing somebody and saying, hey, yeah, I met this person, he or she sounds cool. Maybe Maybe that's somebody that could work for you. without involving yourself too much and putting too much of your reputation on the line? How do you handle this this balance? See what I mean?

Dan Moore 38:52
Yeah, no, that's a really tough thing. I mean, I think that the answer is that and I've definitely made the mistake before of going to bat for people. In some different contexts in a way that they was kind of too much, right? I mean, I think that what you want to do is you want to have equilibrium between how much effort you expend for someone and how much how well you know them and how much effort they expend. And so lots of times, in fact, the thing I just told you, right, where I say, hey, people look on my LinkedIn profile and see whether you see anybody at companies that you're interested in, and I'll be happy to intro you, like I've made that offer 10s of times, and I think I've been taken up on it once or twice, because people, you know, don't want to put in the effort to do that. So I think you can put a few little like steps in the way, then the people who are really focused on it will help but I have found that like, you know, just when you do the intro, being clear about how you know the person and as essentially with kind of newer developers, I think newer developers are hired more for potential and they are I have expertise. And so maybe a little more of a pass or maybe, you know, knowing that someone is good, you know, is a person to talk to and they've been to a couple meetups is enough on qualification. I haven't tried do that with more senior people

Tim Bourguignon 40:18
as often. Do you have any any tips or tricks for for newcomers on how to network better?

Dan Moore 40:25
Yeah. So I think that so there's a couple pieces, right when I already mentioned joining the community, right, and actually being involved in community, I saw a new developer actually step up and help organize a meetup. Because honestly, organizing meetup is not hard. It's hard work, but it's not complicated, right. All you need to do is volunteer for something and you can find speakers or you can like run a meeting which you know, is terrifying the first couple times you do it, but afterwards it gets easier. So I think volunteering is a great way to do it. I think also even just practicing networking conversations. And I think that one key thing that I've learned over my years is that people love to talk about themselves. Thank you for having me on. And so, in any kind of conversation that I have, where I'm talking to strangers, I try to give people information about me that that they might want to ask questions about, or try to get information about them. Right. So I might say something like, you know, I've worked with ABC and D. You know, what have you worked on lately, right? And so give people real conversational like hooks is what I call them. Because otherwise I find that it can be too easy to kind of just end this again. I'm Miss whistle for this now. They can be too easy. stand around and just eat your pizza at a meet up and not actually engaging conversation. So be to other people, and, and then the other kind of piece of advice I would give is, is do the follow up, do the work, right? Like no one is going. I mean, some people might help you out, goodness their heart, but even then you can help them help you. An example of this is I was getting an introduction to a possible employer a couple months ago, and the person who the intro said, Hey, can you write this up for me? And you should write up something that says, Why the company is awesome, why you're awesome, why you'd be awesome at the company and put it and I might modify it a little bit. She basically said, but I'm gonna send this on to them. And that made me really think and that was extra work that I had to do. And again, if I hadn't been missing the company, I might have just said, No, thank you. Or ghoster, which would have been even worse, but, you know, doing those extra steps of effort will differentiate you because it's not it is it is actually astonishing to me how hard how easy it is to differentiate yourself. You just have to put in a little bit more effort.

Tim Bourguignon 42:59
Yeah, that's That's very important, thank you for saying that the showing up is really part of the success. We tend to, to, to minimize this, this impact but by showing up, you're already doing a lot of things or a lot more than the rest of the bell curve. And so then you can start stop to find for the, for the, for the best places in big air quotes or the better recommendation or better networking but already being there. It's already a very, very, very effective. That's, that's true. And when when networking trick I would like to add and I try to place this once in a while because it was so forming for me is asking people for referrals related to it. A special topic. So for instance, I was I'm very interested in mentoring and I've done this countless time at conferences or meetups is getting to, to someone and asking, Who here in the room would be interested in talking to me about mentoring? I'm new here, I know nobody. Do you have any idea who I should be talking to. And this is very effective, because it doesn't lock the person in into the discussion. If the person is indeed interested in mentoring, then they will start talking to you. But they have a very easy open door to close a discussion, meaning I don't know anyone here either or you can go talk to Bob. And then Off you go, and they're, they're free and they don't have to talk to you. And this has worked so so well, for me, having this this to this, this question, this open question where people can really decide If they want to engage in engage in the discussion or not, and that helped me to some, some cold introductions to people and start the talking stuff.

Dan Moore 45:10
So when you say cold introductions, do you mean that like, like, the person will be like, you should talk to Bob, and then they'll pass on to Bob? Or is it more than cool introduction is the person who asked the questions out.

Tim Bourguignon 45:23
Both of those, the first things for instance, I remember I was I was invited in Poland, and I didn't speak language. And that was the only non Polish speaker there. And it was kind of hard to get to start a discussion. And so I use this trick. I went to one of the organizers and say, Hey, I currently I'm one of the only non Polish speakers here, who should I talk to, and there it works very fine. He started being interested in what I was interested in. And so we talked for for a couple hours together and then he pushed me towards somebody else and say now you should really talk to this other person and I would never have known that this person were there and that he was interested in this case, he was interested in this topic. And so I got both in some some Kickstart to get a discussion going with this organizer, and then some help to find the correct person.

Dan Moore 46:21
That's awesome. I definitely I've never used it for filtering people interests. That's but it's a great trick for that. I've definitely used it for jobs. Because I feel like when you reach out to a network and you say I need a job to somebody that to your point Amelie put them on the spot like I'm sorry, I don't have a job. Did you say Do you know anybody who's looking for my skill set against the same kind of thing where it's a soft out like you need to either say no, or they can think or they can say oh, I am. So absolutely, totally agree that th at's a but I've never thought about using it for interest purposes too.

Tim Bourguignon 46:58
And I have never used it for searching for a new job, cool. Thanks as well. Okay, um, we are kind of reaching the end of the interview. What advice would you have for newcomers, no industry, maybe maybe one of the the top three advices of your book that you really want to give towards people that have less than five years of experience?

Dan Moore 47:30
Yeah, so I would say two things I would say, first is never stop learning, right? I mean, I'm now doing Developer Relations, a fusion off a company that is in the identity space. And so I'm learning about identity. I'm also learning about Developer Relations, because I haven't really done this before. And I think that is a joy and a terror of software engineering as a technology as a career is that you should never stop learning. And that's fun, but it's also Sometimes it gets tiresome, but find ways to always be learning would be one piece of advice. And another one is, I think that there's four things you need to do as a new developer to really stand out. And I've run this by a couple managers, I'd love to hear your feedback on that, too. It's, say what you're going to do, and then do that, right. So be open on communicating things and fall through, ask good questions. And that both means researching. But also it means knowing when to stop researching and spinning your wheels and just ask somebody who's a senior developer or somebody who might know the answer. Handle mistakes well, which means you acknowledge them, you fix them as best you can. And then you learn and don't make the same mistake twice. And then the last one, which you kind of already addressed is showing, showing up consistently. Like if you show up consistently every day, and you put in a higher effort every day, you will get better at it. When you're a new developer. I remember I was a new developer and I was learning like, even just learning Oh, moving from Perl to Java. Like It's so hard, and you feel so overwhelmed. But if you show up and learn a bit every day, eventually you'll get to the point where things are ingrained in your mind. And I look back on things I look at, I look at things I do now. And I know I would have had a heck of a time doing them five years ago, or 10 years ago or 15 years ago, and now I just do so those would be my pieces of advice.

Tim Bourguignon 49:24
Hmm, that's really why so say what what you're going to do do it and know when to ask questions. Be sure you know how to handle mistakes and show up. I I would agree. I would agree. Um, I would be missing one one piece maybe, that would be the the "reflection" piece and the the stopping, thinking back on what you did and and learning from from the past. Maybe

Dan Moore 49:57
That's a that's a good one. For sure. I mean, I don't know, I, I had a great post guest post on the on the blog, actually, it was talking about a journal and this this person who wrote this book journals like exhaustively and I don't have that experience, but I definitely blog. And that's been one of the ways that I capture things have happened. I'm like, Oh my god, I never want this happen again, or I want this happen again. I write them down in a public way. But you're right. introspection is is definitely that should be. That should be the fifth thing. Thank you.

Tim Bourguignon 50:31
My pleasure. My pleasure. Well, then, um, where could the listener start a discussion with you network with you or find your book? Where should we send them?

Dan Moore 50:43
Yeah, so I'm on Twitter. I'm at mooreds. And then the blog that was the genesis of this book was his letterstoanewdeveloper.com. So I'd love to have a contact form there. And I would love to just Ask answer questions if you have questions about development. Again, don't ask me what kind of react like middleware you should use in a dap. But if you want to talk about like big, bigger picture developers, like soft skills stuff, and then too, I also am looking for guest posters. So I have had guest posters that have had 2030 years of experience, and I've had guest posters that have been a month into their first job. And I think everyone has something to teach and everyone has something to learn.

Tim Bourguignon 51:31
So thank you very much for sharing your story with us. And this has been another episode of developer's journey, and we'll see each other next week. Bye. Tim from a different time and space with a few comments to make. First, get the most of those developers journeys by subscribing to the podcast with the app of your choice, and get the new episodes out to magically right when they air. The podcast is available on all major platforms. Then, visit our website to find the show notes with the old links mentioned by our guests, the advices they gave us, their book references and so on. And while you're there, use the comments to continue the discussion with our guests and with me or reach out on Twitter or LinkedIn. And a big big thanks to the Patreon donors that helps me pay the hosting bills. If you can spare a few coins, please consider a small monthly donation. Every pledge, however small helps. Finally, please do someone you love a favor, tell them about the show today and help them on their journey.


📖 Browse the amazing books recommended on the podcast.

📢 Subscribe to the podcast now!

Copyright: Tim Bourguignon