If you would like to support Dan consider getting his book with 20% off (expires in Aug 2020) use coupon GiveMeMoore08 – https://www.apress.com/us/book/9781484260739

What we talked about:

• Letters to a new developer. https://letterstoanewdeveloper.com/
• Editors and IDEs
• Mistakes
• Perfect the Enemy of the Good 
• Starters vs Finishers
• Top 4 Things to tell new Devs
• Imposter Syndrome / Overconfidence
• Don’t bag on other people’s code
• Should You Start Your Own Consulting Company
• Best Code is No Code

Transcript:

Douglas:  [00:00:00] welcome to another episode of the junior to senior developer podcast. I’m Douglas Hirsch.

Tyler: And I’m Tyler Lemke today. We’re here with Dan Moore. Dan Moore has been programming, for about 20 years now. He’s worked at large companies like Oracle and level three, as well as small companies, startups and academia.

He’s run his own consulting company. He’s an author blogger presenter. It sounds like you’ve done it all, Dan. thanks for coming on today. Do we leave anything out there?

Dan: No, but thanks. Thanks so much for having me.

Tyler: Yeah, so we, it’s really cool. Cause we actually connected through LinkedIn and we found that we share the same passion.

You have this really cool website called letters to a new developer.com. Can you tell us a little bit about the background of that

Douglas: website?

Dan: Yeah. So about, I actually wrote a technical ebook that I’ve self published in 2012, 2013. And it was a [00:01:00] 45 pages and a lot of effort. Yeah. And I decided that, as soon as we actually, as soon as we started, as soon as I finished the book, it was super esoteric.

the company I was at stopped using the technology. And so I decided that I wasn’t going to ever write a book again about a technology because I’ve been a Jack of all trades. Throughout my life and my programming career. And I just couldn’t see coming to another technology enough to make it worth that investment.

and about two or three years ago, I started to think about maybe trying to write note or book and kind of spitball some ideas. And I thought of, I want to think of something that was more evergreen and that could actually help more people broader rather than deeper. And I, had been a senior developer and a team lead and engineering manager, and I decided to write something and I’d also talked to a bunch of.

Bootcamp grads, new developers and realize there’s a lot of stuff that after a couple of years you get [00:02:00] internalized. And I decided to try to write that down in a blog form to see whether I could help people. And then, the back of my mind where there was always the idea of Oh, I could turn it into a book.

I’m of the mindset that. You can’t write 10 blog posts about something. You definitely shouldn’t write a book about it. The Congress is necessarily true, but, yeah, so I started writing it and what’s been really fun is now that I have a little bit of following, I’ve had a couple of posts trend on some social sites and I have decent traffic.

I’m actually able to use as a platform for other people. and they’ll write guest blog posts. And I think some of them really enjoyed that experience. So yeah.

Tyler: Awesome. You got it. You got the next question, Douglas.

Douglas: So I’m going to say that kind of read my mind a bit. Cause I was looking at that and I said,  this could actually have been a book from the beginning. when I went back and looked at the first couple of posts, and are really enjoyed reading the articles on your blog because they’re.

They’re [00:03:00] concise, short and have good advice in them. the first couple of posts or are, learn versus control. Well, I mean, that’s really important. We happen to teach our, and I don’t know if you know the stamp, but I do work for a coding boot camp called Coda. I’m a web development instructor and we teach version control, like from almost day one.

So it just gets crazier and crazier. Let me start learning about this thing called get all through the five months and, that they’re there and, it just gets yeah, get pretty crazy. So then on top of that, that it was learn a text editor. Guess what?  we say here’s a text editor and then we show them an IDE and we take them up through that list of stuff.

And so  I thought the, the posts were really, really good to someone who may not have had that exposure. Especially, maybe even the person trying to push into development, not necessarily even a new developer. I saw some stuff in there that would make sense even to the new developer. do you think that was part of your target?

Two was to [00:04:00] like hit the aspiring. Developer,

Dan: I wouldn’t say the blog  and I don’t want to talk too much about the book. Right? Cause this is not like a book advertisement, but when I wrote the introduction to the book, I actually thought about who I wanted the book to be for. And that it was, it’s a bunch of revised posts.

So it’s not just the content, but I really thought of new developers first and foremost, and then aspiring developers or people considering that because. the content of the blog is such that it’s some of it’s technical, right? Like my wife, who’s not a developer. We have no idea what version control is.

But I try to explain things in concepts that people who are reasonably capable with computers would understand. And then third one was actually mentors because I thought that the book would be a nice. Discussion point, or like study, not necessarily study guide, cause it’s not that structured, but  basically  a third voice to bring into mentor mentee discussions.

But, certainly when I was starting the blog, I did not think about, helping out aspiring developers at all. It was really here’s [00:05:00] some dumb things I’ve done, please don’t do these dumb things.  and I have my own dumb stories about guests. Or text editors or other mistakes I’ve made that are more kind of people oriented.

And I was trying to document those so that people could look at that and just understand. there’s a world of difference as I’m sure both, you know, between learning something by. Touching the stove or learning something by reading the manual and the manual says don’t touch the stove.

Right? And the book is definitely, or the blogging. The book are both definitely that second category, but still it’s helpful to know that there is such a thing as a still.

Douglas: That’s right. That’s right. No, we talk about on this podcast, we talk about the difference between, declarative and procedural knowledge all the time.

The declarative is I know what stoves are, or I’ve read that there are such thing as stoves and they, they produce heat and the procedural would be, I tried touching the burner in it hurts. So I will never do that again. [00:06:00] Yeah.

Dan: I’m actually, I mean, I listened to like, I think an episode or two and I’m, I was.

I’m really looking forward to it. I’m really important. Yeah. Just because I think you all have like a much better theoretical model of learning than I do. I have never studied it. I’ve never really done anything other than self-education. And I can tell both of you actually have some, no theoretical underpinnings of how people actually learn, which is fantastic.

So I’m looking forward to discussing that

Douglas: too. Yeah, for sure.

Tyler: We can definitely definitely touch on that. I think so. I think it’s interesting. what, and we didn’t talk about this before, but, what. Who do you think will benefit most from your letters to a new developer website? And this is, just to clarify, this site’s completely free, right?

So, who would benefit most from that? Or are you seeing that, that, brand new developers like are aspiring developers? Is it junior developers? Mid-level developers. Who’s who is it? Mostly targeted towards?

Dan: Yeah. So, you know, when you [00:07:00] put something out there on the internet, it’s really hard to know who is actually reading it.

Right. People reach out to me. And so, you know, I have some anecdotal evidence and the people who kind of talked to me about it on slacks or at meetups have been newer developers. I have had, there’s a, you can sign up for free the newsletter, which just basically sends you the blog every week. And I have a little field there, which says how many years you’ve been it on that.

And I’ve had people sign up with as many as 20, you get three years of experience, but the vast majority is five or less. The people who choose to tell me. Right. so yeah, so I think it’s really a target is I’ve graduated from a code camp or a CS degree and, or I’m in the middle of it. And I realized that there’s a lot more to software development than programming.

Programming is hugely important. Don’t get me wrong. You know, you can’t, you can’t be a developer without being able to program, but there’s so much more [00:08:00] comes into delivering software.

Tyler: So it sounds like it’ll be really beneficial for, anyone else that’s looking for more, more content and likes our podcast.

So that’s, that’s cool. so you, you have several different, I don’t know how many, Douglas wants to cover, but you had several different, cool articles that I, I liked, And Douglas, you touched on, you touched on a few. I remember you talked about one here. the, that your very first post was learning a version control.

did you want to go into, did you have a followup question on that Douglas?

Douglas: No, I just, it was more of kind of giving an idea of, of the kind of knowledge and the brevity, but the value that the, the articles, the articles provide there wasn’t, you know, I think, I think as, as seasoned developers that have that well, As we, we actually have different experience levels here, but as someone who has done this for a long time, I actually absolutely do subscribe.

[00:09:00] Now, my only question to you, Dan, is that VI or Emacs,

Dan: you know, I, I’m a

Douglas: via text editor itself.

Dan: I’m a VA person myself, but I have, I have friends who use Emacs. So I’m ecumenical. It comes to that.

Douglas: That’s okay. We’re we, we, we are inclusive of text editors.

Tyler: I thought we were gonna kind of cut off politics Douglas, come on.

Douglas: So, so that’s actually really funny, Dan. I am a, I spent a couple of months of my life in them just to like, get my, just to really get. Into it and understand it. So now it’s like, like I just jump in there and it’s like riding a bike. I don’t every, I don’t know everything and well, actually anyone who claims they know everything about them, they’re lying.

They’re lying. Do you have a 20, you know, unless you’re, unless you’re a, what is it? The, you’re what is it? The VMRC we are, you know, unless that things like, like 20 years old and you’ve got probably still even have stuff in there, [00:10:00] remember that you put in there, you know, that’s, that’s a, that’s a thing, but no, you absolutely should choose an editor now.

That’s. Now, whether that’s like, like in, in today’s world that like vs code as your text editor or sublime text or, or whatever. And even that causes fights, like I have my co-instructor he’s like if, if I had opened that in sublime text, it already would have been opened by now and vs. Code takes. Two seconds to open it.

He’s right. He’s right. I mean, vs code is an electronic based app and, and sublime text is a C is I think a C plus plus app and it’s native and it just like it. They barely even, you know, they even bleak. Go ahead.

Tyler: Do a bunch of optimizations though. That’s why, if you guys remember Adam and brackets, the reason why the S code is so much faster is because they’ve done a bunch of optimizations.

on top of, electron to make it much, much faster, like they were at a bunch of stuff and like C and C plus plus, but, yeah. yeah, I liked vs code more. I, I haven’t done jumped [00:11:00] into the Emacs or, you know, I can’t, I, you know, The little experience I have when I can’t even exit a commit message. I just, you know, I just, I just, it was like, I don’t want any part of this.

So I guess I just put my tail between my legs and ran away from those editors.

Douglas: Oh, man. The only reason why. And actually I would add to that advice, which is like, learn, learn at least how to get out of VI because, or how to save and how to get out of VI. Because if you have to jump into Linux boxes for any reason, it’s or actually most Unix. Are positive space boxes vis everywhere.

You can always get a VI editor up and running, but nano may not be there if you need a regular type editor, man, I’ll tell you, we’re getting into some stuff here. He

Tyler: didn’t know. We’d go this deep on down.

Douglas: Flaming going on. What do you, what do you meet him? EMAC. What is he backs?

Tyler: I use an iMac. What are you talking about?

Dan: I mean, I, you know, I mean, [00:12:00] I will say, like I bought a, so I bought that blog post and I shared it around and there were some people flaming me. Right. Who said, you know, come on, you don’t really need to know a tech editor. Like you can do stuff from within your ID. Yeah, yada, I’m way more productive in my IDE.

And so I actually ended up bringing a companion post that was learning IDE because I think both of them are valuable. They’re just different tools, right? It’s like I have a hammer and I have a saw, what am I going to do? Well, there are things that the hammer is appropriate for and the things I saw is appropriate for.

And you should, as a, as a professional developer, you should have a working familiarity with both of them. I think. Your your point, Doug Douglas is mastery is a long way away. Right?

Douglas: Good. You should have a good set of tools. Right. And I mean, the text editor is great for. you know, not every developer in the world, every developer is going to be jumping into Linux boxes, but I’m going to tell you when I am in one and I can just type VI whatever the file is and start editing and no con you know, no, mostly what I’m doing in there. [00:13:00]

and I didn’t have to install anything to get that to work. I can just jump in a box and rely that it’s it’s there. So that’s a good text editor to know just for that. That’s the, that’s the scenario, that’s the tool. Where, where you might want to really be good with an IDE and, you know, for your day to day, like your entire job, like if you’re doing Java, you know, the, intelligence is a really, really good IDE for Java.

I mean, I’ve, I sit in intelligent now a lot. I actually teach from intelligence, but I used to use something in the.net world called ReSharper. Back in the day, like long time ago, used it for the longest time. Like as long as I was a professional, dot net developer actually still kind of am, but, I have the re I have the JetBrains toolbox, which means that I have all those tools if I need ReSharper I can bring it down, but I’m on a Mac now.

So I’ve been using their C-sharp IDE, I think about that. They’ve made a C sharp IDE for Mac.

[00:14:00] Dan: I mean, thinking about the supported, like the Le the Linux subsystem and windows 10, right? I mean, yeah. It’s a crazy stuff. It’s a crazy different world, right? Like, so. Anyway, so

Douglas: no, no, no, no, no, no. It’s it’s it’s cool.

I kind of like Tyler, I, you could ask him, I like reminiscing about old stuff like that sometimes, but also another post that I saw from you that I really thought was a very encouraging post is you’re going to put some plates in toasters. That one stood out at me as I was scanning through. you know, it’s this back it’s for back in may.

I only went back into it to like January the end of January, beginning of February. So this was one of them where I thought the story was hilarious, but it is definitely, It definitely kind of goes down our path of, you know, you got to do things and fail and you’re going to fail. Right. Just be okay with that.

So, you know, we, we tell our students [00:15:00] and I refer back to that a lot because as a student of software development, And as a new developer, you’re going to fail. And I remember failing a lot and how bad it felt. I just tried to make, tell them, look, you’re going to fail. It’s good to feel bad about it.

Cause that means you want to fix it, but try to work more on fixing it than the feeling bad part. That’s, that’s kind of the way that I’ve put it. What do you, how do you approach that?

Dan: Yeah, so I, I think of it in terms of mistakes and there’s actually, I had no posts where I have an entire. A chapter about mistakes.

And, you know, I mean, to me, the important thing with mistake is one acknowledge or first realize you’re going to do it right, because everyone does. And, you know, an example of a mistake that I made. Not in the too distant past was I thought the first time I was using getting a team setting, I thought that the way to check out our branch was to get checkout dash B, which is for anybody who is not a good person, that actually doesn’t.

That doesn’t [00:16:00] check out our branch that actually creates a new branch. And so I was checked, creating new branches that already had remotes that have the same name and that would pull down the remote. And then I would basically be doing this, like mish-mash merge of these branches in a way that was totally unintentional.

And luckily we didn’t push code to production that was there, but. I made the mistake. I admitted it. I worked with a team member to fix the mistakes that I’d made, that come out of that. And then I made sure that I, I learned enough get to be better and to make sure that never happened again. Right. So those are the three stages of mistakes from my mind.

It’s like, no, there’s, you’re gonna do a mistake. When you do acknowledge it and then three take steps to prevent it from happening. And that could be learning something new. It could be an automated system that you’re going to implement. It could just be just writing a blog post about it so that it’s seared in your memory.

it doesn’t, lots of people I know have notebooks, right. That they write stuff down and that doesn’t work for me, but I know it does for other [00:17:00] people. So, mistakes and failures happen all the time. And. Even people with 20 and 30 and 40 years experience still do that. So, but the scope changes for sure.

Right. I wouldn’t expect somebody with 10 years or 20 years of experience to make the same kind of mistakes as a, new developer, but the experience of failure persists. For sure.

Tyler: So I have a follow up question to that, cause I think it’s, Cause I think you wrote, like never make the same mistake twice.

I wanted to get your, and I didn’t read through going through a lot of them pretty quickly, but what’s your feeling on like, if you were to make that same mistake again? when do you think it’s acceptable and make the same mistake? The, to make the same mistake, given that where there’s so much complexity involved with software development.

Dan: I mean, that’s a really interesting question, I guess I would say that. The goal is never to make the same mistake. Right. now I guess you could [00:18:00] start to like, hedge and think about what the word same means in this context. Right.

Douglas: I was thinking that

Dan: to your point. I mean, Tyler, like, yeah, there’s so much complexity.

you know, if I did that same thing about branches with mercurial or something like that, and that might be a permissible stake. I mean, I guess the goal is. I think that the goal behind don’t make the same mistake twice is that you want to give permission people to make mistakes, but you want to have some kind of mechanism to encourage them to them, to learn from them.

Right. So that doesn’t mean that anyone’s perfect. Right. And if you make the same mistake, five years after a year after. you made the original mistake, you know, we’re all human, but I really wanted to kind of try to put 500 people’s butts to like, make them realize that we should, we have the tools aren’t automation around learning.

To, to not make mistakes repeatedly, but it’s totally okay to make new mistakes. Right. [00:19:00] And that’s, that’s actually, one of the goals of the blog is just, I want everyone to make new mistakes because you should be able to learn from other people’s mistakes. Does that? I don’t know. I may even be like wishy-washy here.

I don’t know. That was a really,

Tyler: I think it’s fair. Yeah. I think, I think it’s fair. Just think, I find it’s easy. I think I th I find it’s easy to make the same stakes when you don’t use the same technologies all the time. So let’s say you went away from get for a while. A long time. I find it’d be, it’d be easy to forget and have that fall out of your head and go.

I forgot that, you know, How branching works because I haven’t used it for six months. Right. And so I think it’s, I think it’s just interesting balancing those two, but I do think it’s very liberating. How, how is it, you know, you know, you know, don’t be so hard on yourself, right? Cause I think, there are some, some people out there who are hard on themselves, there’s other people who don’t, you know, don’t take responsibility and are hard enough on themselves.

You have the opposite side.

Dan: I think they would say honestly, [00:20:00] especially when you’re a junior to junior to mid dev. Like you want to be proving yourself, right? You want to be excellent as excellent as you possibly be in a good way to do that is to take note a mistake and then like set up a system or a learning thing to make sure that you never do it again.

And to your, to your point, like maybe the answer is you just decide, Hey, if I go away from technology for a little while when I come back to it, I’m going to revisit my notes or I’m going to take a 30, you know, Find a tutorial or something like that. And that’s enough of a system that you are going to prevent yourself from doing that.

But I mean, I can tell you, like, I’ve been an engineering manager twice, and that is like an entirely different profession than, being an individual contributor. And I made multiple steaks. repeatedly with, with, with engineering management, because it’s not grounded into me the same way that I see mistakes.

I like to think I don’t make the same mistake around just playing a Colby coding anymore, but I, I wouldn’t. I, if you, if you, if you may [00:21:00] be, if you hope, if you, what’s the word I’m looking for? If you maybe about my life on it, I probably wouldn’t that I’ve never made mistakes. The same mistakes again.

Sometimes you just forget mistakes, which is nice. So

Douglas: that’s, we’ll say that, that the, the idea that you could make the same mistake in management. More than once actually makes a lot of sense, because you may not even know, realize because computers are, are really cool because you could write the code and if you write it wrong and you learn how to write it correctly and can remember how to write it correctly, it will continue to do the thing correctly.

But with humans, you can remember how to say the thing again, but to the next human that you say, that thing you might be making the same mistake you did before. Even saying the thing, the way you thought, you know, giving the advice the way you thought you should, because everyone’s experience of reality is a little bit different.

So the language that everyone uses his entire can be, can be [00:22:00] just nuance slightly different enough to. You know, just, just that nuance can be just off a little bit where you could have hit, hit the same brick wall and not realized you, you had done it. And, yeah, management’s been something that, that I try to, I pulled, I pulled a little while as a CTO and, and.

I’m kind of happy to go to B to be doing the instructor thing and not having all, having the butt kind of stop with me. And that in that realm,

Dan: I definitely it’s different, different set of responsibilities, for sure. For sure.

Tyler: So I think it’s, I think it’s interesting that you bring that up. Cause it reminds me of like, I feel like not enough technical books go over the.

The gotchas to different, like the gotchas different thing. And I think part of that is because people who write technical books maybe have so much experience in that technology that they forget how hard it can be. when either when you’re brand new or if [00:23:00] you’ve been in technology for a long time, and it’s just a brand new framework.

But, I like to think of, you know, the mistakes as maybe like, if you remember playing RTS is back in the day, like red alert. I used to love red alert, The game shroud where you, I don’t know, what’s on the map. Do you think of it that way? Like, If you make a mistake, you’re kind of defining the boundaries of what is it exists within JavaScript or within, you know, Ru I know you’re a Ruby dev and you’ve done a lot of different, you’ve blogged about a lot of different technologies and you

Douglas: kind of

Tyler: circle get the map until you kind of discover, Oh, I’ve made all these mistakes now.

And your mistakes are kind of representative of you going to the different areas of the map and going well. I ended up over here. This is the totally wrong place. Like there’s no one over here. There’s no resources. I can’t do anything over here. I think that’s kind of how learning works is you kind of just eventually discover what we’ve both, what Douglas and I have talked about is this mental model of, of the different technologies that we learn.

But one is [00:24:00] a transition to something else I think is kind of similar to mistakes is you have another blog post, and it’s really cool about these blog posts, who is their, their, Douglas doc touched on as these are like really consumable. These are not fluff pieces that like go on and on for 2000.

Words, right. They’re like, yeah. Good for Google. I like how they’re condensed and very consumable. And you talked about, the perfect being, the enemy of the good and some of the questions that you, that you talked about in here was how often will be, how often will this, this be used, like, like how often will this, feature be used?

Like, is it going to be used once a second, once a year? Once, what are the risk factors if it fails? what is the team quality ethic? I want you to touch a little bit more on perfect being the enemy of the good and how many times it’s burned you personally.

Dan: Sure. yeah, I mean, so I think, that, [00:25:00] that, you know, you know, I do a world.

Where we were all artists that had the time and money I saved. Yeah. You can write some really beautiful software. The unfortunate truth is, or the fortunate truth in some ways is that. Software exists for a purpose, which is to accomplish some goal. usually it’s a business goal. At least that’s been best majority of my experience.

And although it can be a side project where it’s just a goal to learn and have fun, which is a totally different experience and has a different set of constraints. So once you get there, you’re, you know, once you accept that your software is lives within a constrained world research in the chain world, you need to make trade offs.

And the most important thing about tradeoffs in my mind is not to make them unconsciously. And so I don’t think that at every meeting or every sprint planning session, you should like break down like, Hey, this is exactly what we’re going to try to do. Right. Like, this is only gonna be used one time, so [00:26:00] let’s go ahead and we can write it like in bash.

Right. And just like, and I’m put in birth control. Right. but I think that. When you are confronted with the problem, especially to me, it’s taking you a while or that you predict will take you awhile. I think you want to have an honest conversation with your team and with yourself over what’s good enough to, to ship and what’s good enough to support.

And then also, you know, so what you don’t want to, You know what won’t cause more problems than the lie. I’m an example of this and I, I think frankly, you can be surprised, right? Because what you, we tend to be, we tend to yeah. Have high standards, especially. I think the people that are listening to your podcast are probably people would want to improve themselves.

People that are really interested in software. And I remember a startup, I worked at, a co-founded actually I was. Putting together like a MB MEP and my co founder. [00:27:00] And I were both just so embarrassed and I was embarrassed because I built the software and I, I knew what really great software could look like.

Yeah. She was embarrassed because she had a vision in her head and we showed it some users who it was actually solving their problem for. And they’re like, Oh my God. This is so much better than anything that anybody’s shown us. And so I think shipping something that will work and we’ll write things right.

But like the, and I think I might’ve put this in the blog post, like the most perfect, awesome extensible, beautiful unit tested piece of code or tested piece of code that doesn’t get shipped. Doesn’t do anybody any good? And so, I think that you need to, and this actually is. I noticed in some of your podcasts, you talked about like what makes a senior developer?

I think that having that awareness of those trade offs is a good barometer of how senior you are, because you’re aware of all the other kind of pressures that are around your coat. you know, so, [00:28:00] yeah, so that’s what I would say about, of perfectly good. Oh, there was a second part of your question, but I don’t recall it.

I’m sorry. I

Tyler: just wondering how many times it’s burned you, because I feel like it, it gets me a lot, or at least I tend to overthink, what I’m developing. and it makes I lean more on the side of perfection versus shipping personally.

Dan: Yeah. That’s actually a really interesting perspective because I tend to lead it.

I’m more pragmatic. Right. Which probably means I’ve shipped stuff that was. Less quality than it should have been. which is why I’ve gravitated more towards the startups in Canada, the smaller companies, because if you screw up, like it’s, you know, I I’ve screwed up in having to call users before, but I didn’t have to call a thousand users.

I had to call like 10, right. And apologize to them for the mistake that I’d made. So I think there’s spectrum. And I think, you know, you want. People have their own predilections and then the code itself and the requirements around that code have their own, influences as well.

Tyler: That’s actually really

Douglas: cool that you’ve [00:29:00] mentioned that, that like you have this strength that you can put out code that does that.

And I don’t want to say mostly works, but, but you can put, you have like this, this barometer that you can use, to put code out and. You know, you said you’re more pragmatic. So sometimes it gets you get, it may not be as high quality as it should be. And that kind of gave you that, that push towards startups.

That’s actually a really good awareness that you’ve got over the kind of co or not even the kind of code, but just how you want to write code your streets is what is what I’m getting at. I just read a book or I’m reading. the, the tools of the Titans by Tim Ferriss and in there, he talks about success is finding your it’s, it’s finding your, your, what you would think is your weaknesses, but actually, building them up as, you know, actually focusing and exercising around those and making them your strengths.

And so what you just said was kind of an illustration of this point that just got hit into my [00:30:00] head while I was, driving in the car with dinner home, you know, on the way home. And, I thought that that’s actually really cool that you said that because you know, some people would say, and I have a hard time with that.

I have a hard time writing code that isn’t tested that isn’t, you know, it really kind of bothers me. It makes me lose sleep at night when I do that. And so I want to go to places where they’re like, we need the code, right? The first time I’ve written a payment system before that code could not, if someone.

Did a transaction for $10 could not pull a million dollars out of their account. And I had to prove that it wouldn’t do it. Okay. I really loved writing that system where it makes me really nervous to write stuff that I don’t have like a full test suite around. And I can’t, I can’t control it, but I have worked in startups too.

But I think you’re right. I think you should absolutely go where your streak is. This is more of an observation of what you just said. I really loved it that you, that you actually said that out loud and, and, [00:31:00] and, really liked that.

Dan: Yeah. So I got a couple of, couple of things to say there, like one is I’ve written a payment system to, and I wrote a lot of tests around it because I think there are things that you just.

That’s a case where the situation, the code made sense to make it more robust. Right. but even then I still had mistakes. Yeah. Still wrote tests for the new mistakes. The second year is that, I had a mentor once who said that there are people who are good at starting things, and there are people who good finishing them.

Right. And so people who start, you can give them a blank canvas and they’re ready to like dive in and explore things and figure it out. And there are other people who, when they see a blank canvas are kind of like, Oh my gosh, I’m not quite sure where to start. And they like Kevin Hyde. And then there are people who are really good finishers, right?

Who things all the way through who documents stuff who are really good at maintaining things. And again, I think you just need to pick your pick, your they’re both necessary. Right? They’re both great. Attributes to have you just need to find what [00:32:00] resonates with you. And then a third thing I would say is my current job is actually Devereaux and I migrated to this in part because it is a great job for me in terms of.

You know, I’m running a lot of code and code examples, but it’s not, it’s going to be an example for someone to take and productionize, right. Or to build on within their own system. It doesn’t necessarily need to be, you know, a full on, you know, fully tested, like robust production system because it’s example code and

Douglas: mission critical when it’s example.

But your example code can help your company immensely poet. Yeah, no, I love it. I really liked where this went.

Tyler: So I think, I think Douglas and I might have to write a book called the paranoid paranoid program or something like that. It’s like the opposite of refrack Radek although, although Douglas is very pragmatic, I think I tend to be a little bit more dog dogmatic on things, but, it’s actually, I think it’s actually good.

I kind of, [00:33:00] I’ve kind of learned from my current role that it’s good to have a mixture of different types of devs on teams. To help move things in and have a good balance there, I guess kind of like a, a, maybe a, you know, a good partnership or marriage might have a mix of different strengths and weaknesses.

So, so what are your. What are your, I wanted to go, what is your top three things that you like to tell new developers, either from your book or from the, maybe from the letters to a new developer? I’m sure a lot of there’s a lot of overlap

Dan: there. Sure. Yeah. Especially a little bit and make it four things.

I, and I’ve actually done a talk, based in part on this. I think that there’s, you know, obviously we’re talking about technical skill, right? And I’m not like, if you want to ask me about react or like Liz hot technical thing, I’m not the right person to talk to about that. so there’s that aspect of development, but I think that as a new developer, there’s, if you do [00:34:00] four things, you’re going to really Excel.

And I think that that is, Ask good questions. And that’s a balance between doing your own research, but also knowing when to stop because I I’ve done, I’m sure we’ve all on this call have done this where you reach your research yourself into a, into a spiral. Right. And you’re just like digging up, digging the hole further and further, and you’re like banging your head against the wall and then you talk to somebody and they’re like, Oh yeah, yeah, no, this is the reason why it’s like this.

And you’re like, Oh, if I only asked you an hour or two ago, but doing some research, but not too much. So asking good questions. Mistakes. We were talking about kind of taking responsibility for your mistakes and then, showing up and being consistent. Right. Just like trying to be a little better every day, because there is that like flywheel where you will ingrain things, right?

The first time you. have to write a filing VI VI is going to be a painful the second time. It was painful. The third time, a little bit less painful and so on and so forth. And I think [00:35:00] the fourth thing, which I think this is good for everybody, not just developers is to. Do what you’re say, what you’re going to do, like communicate what you’re going to do and then do it.

And I struggled with this myself because it’s very easy for me to overcome it. And, but I think especially as a new developer, a new person on the job, it’s better to commit. To less and really knock it out of the park than it is to, or, or even just really deliver it on time, the quality level, in fact, than it is for you to say yes to all kinds of stuff and then get overwhelmed and not be able to move forward on anything.

So those are kind of four pieces of advice I’d give.

Tyler: That’s cool. Cause it reminds me, I think in that if I’m not mistaken, the perfect, the enemy of good or another article you wrote, you said it’s better to deliver like 110% versus be like 90 to 95%. So it’s better deliver like 110% of that smaller portion versus 95% of a larger thing.

Is that kind of what you’re getting at? Yup.

Dan: Especially early days. [00:36:00] I think as you maintain, as you gain reputation in a job, you have more room for. Like overestimation, right. Or, or for saying, Hey, I’m sorry. I screwed up. Right. But like, I just. Again, not to harp on perfectionism. I just feel like it’s better for everybody, right?

It’s better for the team. If you commit, tap that thing that you thought was going to take you, you know, if you commit and deliver on this one small thing, then commit to five things and not don’t deliver them all. It’s better for you because you feel better about yourself and you learn more, right.

Because you’re not like you can focus on one thing. So, I’m a, I’m a huge fan of, of, you know, it’s that old. Under promise and over deliver is way better than the other way around. It’s just more fun for everyone. And as a manager, I’ll tell you that’s true too, too, right? It’s way. It’s way better for you to say it’s going to be, I’m going to have it done on Monday and give it to me on the Friday before then.

Vice versa. [00:37:00] It’s just, even if it’s a small thing, those things add up.

Tyler: I think that’s great advice. I think that’s excellent advice.

Douglas: I was gonna say the idea about the whole manager and timelines thing. I used to, I had this manager once that, that he would, if I said something was going to take me two months, he’d go, you could do it in three weeks.

But if I ever came to him and said, I can do it in two weeks, he was like, Oh crap. He basically, he was like, dude, you’re not giving it enough time. But if I ever said that, I needed a lot of time for something, he would go, you could do it. You could do anything at three weeks. But if I ever said. Oh, it’s easy.

I’ll do it in a week. He’s like, no, you won’t. I’m not going to, I’m not going to deliver that daddy body. He didn’t trust

Dan: stress summation at all, basically. Or do you not trust anybody’s estimation or what

Douglas: was that? I think it was, I think it was, What is the principle where you’ll take up a you’ll take up whatever time it’s given to a, to a task is, is kind of what, what he always got at.

[00:38:00] And sometimes I think he actually understood what my capabilities were better than I did. And, and also I have made the mistake. I would actually, if I had to do it in three weeks, I would, whether that took, that took nine weeks worth of hours to get it done in three weeks or not.

Dan: So

Douglas: he was right. I could get it done and I can get it done in three weeks.

I just might hate his guts for it after I was done. but, but if I ever said one or two weeks, he was like, he really zeroed in on that. He goes, well, okay. Let’s, let’s figure out why you said one or two weeks. Cause you’re my. You’re like, this is a six week long deal. And, and, so, so he would, he would get real finicky about it, but what he never told me when I worked for him was that he was always telling people when he said three weeks, he was always telling his, his people above him, like four or five weeks.

So he was, he was doing that. I just never do it. But it would be, I don’t know if it would be possible to have that kind of honest [00:39:00] conversation with your manager or not, but I just thought you’re, you’re, you’re under promise and over deliver. It was kind of one of those things where I think he was trying to engineer that in, in, in those time estimates, I wonder if you ever pulled any of those kinds of tricks with when you were, you were in management.

Dan: I would encourage people to, if they gave me a number. I would encourage people to buffer it. I wouldn’t, I wouldn’t do that without their knowledge upwards, but it was at a small company too. but I always, you know, when people would say a task would take 15 minutes, right. And a small task, right. I would always say, Hey, just round up to an hour.

Right. Because for a couple of reasons, right? There’s always things, some things kind of flex around and sometimes some you think is going to take eight hours. Actually she’ll take you 10. And the other thing is that there’s just. Around software development, even a small change to a small site, like documentation changed conceivably, right?

There’s version control. There’s getting it code reviewed. There’s all kinds of other [00:40:00] pieces that go in that you, when you’re a developer, you just think, Oh, I just need to change this function. You know, finding the function where it is and finding what else calls it and updating the tests. And I think that, it’s very hard to internalize that time.

We were all. At least most developers I’ve worked with are insufferable optimists just low. And it’s, it’s good because otherwise it’d be really tough, but like, especially when it comes to time, it’s just really hard. I find it hard.

Douglas: Well, I worked, I worked with this guy talking about, talking about like the, no in it.

No innocent code change. You know, this guy, he was a, you know, much older. He was a smoker, you know, he had this real grumpy voice and, you know, and they called me puppet this job. Would he go, you don’t pop, there’s no such thing as an innocent code change. And that’s just, that’s, that’s stayed with me when you said, you know, that’s, that’s just like, like that’s, that was my first corporate gig.

And, and I sat next to that guy. I was working [00:41:00] on a, Heck, I even remember the computer. It was like a, a Pentium Pentium, four

Dan: he’s fast screaming fast, right?

Douglas: Boom. Yeah, no, it was really crappy. It took forever to compile everything. If you need, if you need to change your head or file you just, you go, I knew why he smoked, you know, physically change the heterophile go smoke, come back and then keep working.

Oh man.

So I noticed something else. Oh, I just happened to have a question that popped into my head and I wrote it down. You know, we talked a lot, you talk a lot to do develop, and I got a feeling that you experienced questions along these lines all the time and people who watch or not watch listen to our podcast, might have the same question, but what do you say about imposter syndrome?

Have you, I didn’t see anything that kind of flew out at me about a conversation about that. Do you, have you suffered from [00:42:00] imposter syndrome? Have, Do you know, you, I’m sure you’ve met people that have, what advice do you give them?

Dan: Yeah. so my wife actually doesn’t talk about imposter syndrome, so I’m kind of a little bit aware of it.

And, you know, I think it’s, it’s, it’s definitely something that I. Have encountered in my own professional career. And I, and I know other senior developers who have as well, there are very few people I talked to that professionally that don’t have some form of this. I think it’s just a natural thing to, to, to feel.

And I think, you know, Just like anything else, the answer is to kind of, work through it. Right. And you do that a couple of ways. One is you can model behavior that you think it should be. You can discuss that with other people. I think that like peer groups are the slacks that I’m sure that all the bootcamp grads have access to are great places to talk about this.

Right. Cause. It’s [00:43:00] funny, you know, one person’s imposter syndrome is another person’s strength. It’s speaking back to what you were talking about, like strengths and weaknesses. You know, some people might have imposter syndrome around front end UX, and other people might have imposter syndrome around data modeling.

And so you can all be supportive. But I think, I mean, honestly, one of the joys and the terrors of being in software development is that there’s always more to learn. Right. And that’s really great in that you’ll never be bored, right? It’s one of the great careers for learning. I’m sure there’s other great careers for learning.

This happens to be the one that works for me, but it also means that you’re always a novice, right. And it can be not maybe, maybe not always. A novice, but you’re often a novice is partly because once you get canvas expertise in something like you kind of tend to admit, at least in my experience, I tend to move on or I tend to bundle it up and like document it and hand it off to somebody else.

so imposter syndrome. Yes, totally [00:44:00] prevalent. I haven’t never actually had somebody kind of come up and talk to me about it, or email me about it. But I think it’d be a great topic for the blog. Looking for guest post writers. If, if you both, you seem like you have plenty of time don’t you guys don’t seem busy at all.

So. Happy to have you, right? I guess lots of work.

Douglas: Just got it. You were joking there.

Dan: Sorry. Sarcasm. The chat.

Douglas: You guys, you guys aren’t doing anything? What? Just write blog posts.

I have an inverted. Sorry, go ahead. No, I was, I had a, I had a thought pop into my head, but I lost it. So Tyler, you go ahead.

Tyler: I thought I popped her thought bubble. So, I wanted to ask Ann verse. I don’t know, maybe you haven’t thought about this since you haven’t written about the imposter syndrome, but have you thought about, are you familiar with like the Dunning Kruger effect?

It’s like the opposite of imposter syndrome. It’s where you think that you’re smarter a smarter than you are at a subject when you’re really new at it? [00:45:00] cause it doesn’t get talked about a lot and I think it’s, Have you, have you ever run into that in your career with either other devs or yourself that’s burned you before or other people?

Dan: Yeah. So there was a time, I don’t know whether this person thought they were. Competent, but they still had a job where they should have been competent and they weren’t. And I was a contractor and I basically had to help them with this project and like drag them through it. And that included some Saturdays and some kind of unpleasant experiences.

And, you know, I was a contractor, so I was getting paid by the hour. I wasn’t thrilled, but it was okay. But I mean, I think that, You know, you just have to. I don’t, I don’t know any way to get people to change if they don’t want to change. Right. So when you come across somebody like that, you know, my best advice is to kind of try to get away from the scrutiny as [00:46:00] possible.

you know, the, the other alternative is like to do politics, right. And kinda cordon them off. I’ve never been really good at politics. I’m just not good at it. And I imagine that would work as well too, if you had that skill sets. But, yeah. So that’s been kind of where my one experience that jumps right to my mind.

yeah.

Tyler: Oh yeah. I think that’s, I think that’s great advice. So you’re saying, you’re you’re saying either get away from that person. So as in like switch jobs or get on a different team, Is that what your advice would be is, is because like, can you, can you explain a little bit more? I think, I think I understood.

Are you saying that you want to get away from that person basically? Cause they’re going to drain your time and resources as well as make you look bad or what’s the, what’s the big underlying underpinning reason to get away from them?

Douglas: Sure.

Dan: That’s a good question. I mean, I think that the underpin, a reason to, to, to get away from somebody who.

Thinks they’re competent, but isn’t, which [00:47:00] I think is what the Dunning-Kruger effect is. As far as I can tell from your, like, I’ve read about it, but you, you have a great summation of that is that it’s going to SAP the will of the team to deliver the value and, to deliver good software. Right. And so if you’re okay, punching a clock and just, you know, Getting getting paid and like maybe delivering less software than you could doing it, less quality you could, which by the way, is a perfectly fine thing to be, right.

Like not everyone needs to be a superhero. And there are times in my life when I was a more of a clock puncher than there are than other times. So I’m not saying everybody eats like. Like be listen to this podcast and always be trying to level up. Like, it’s good to sometimes just take it easy, but if you’re not in that situation then, and the times when I haven’t been in that situation, it’s been really frustrating to me to have someone that you have to kind of work around to help the team move forward.

And so, you know, like I [00:48:00] said, one option is to try and get them off the team. Another option is to move genes or move jobs. And, you know, I think this gets back to something that’s a real interesting point, which I’ve had managers. I trusted at various levels in my career, some high level of trust, some low level of trust.

You know, if you have a management, you have a high level of trust with, I think that. You never want to, you don’t want to throw any team member under the bus because it’s possible you don’t have the full context. Right. And it’s possible. I didn’t have that full context with that guy. That I, I mentioned, you know, being really dissatisfied with maybe he was really, really good at a certain aspect of the job that I just didn’t see.

Right. So, but I think it’s worthwhile to point out yeah. Actions to a manager that you trust and say, Hey, I don’t understand why. Person X is doing this it’s right there. They’re redesigning the database access layer again, right? Like, is that a good thing to do? I don’t. Can you help me [00:49:00] understand why? and that might be, you know, their approach to take, because that’s going to widen your context and there may be a very valid reason.

Maybe the CTO dictated that we needed move to.net core five, and you’ve got to redesign the data access layer. So, I guess that’s a third option, so leave or coordinate them off or try to understand why they seem to think they know more than they do, but maybe you, maybe your eyes just aren’t seeing the whole picture.

Douglas: I mean, you don’t know everything. That’s a really good that third one is like one of my, my favorites when I mentor people and they walk in, they tell you it’s so bad here. And I’m like, well, usually there’s a reason why things are that way. Maybe you actually decided to join the wrong company if you think it’s really bad, but before you go in there and tell them how bad it is right before you do that, you should start asking some very interesting questions about.

Hey, I noticed that we’re doing things like this. [00:50:00] Why, you know, just out of curiosity and, and kind of get that context around it, and maybe there are real reasons why, and that makes you seem curious instead of confrontational, they both start with C one will make you friends. The other one will make you enemies.

Dan: I, I wrote a blog post called, well, again, I don’t know if I can curse on this podcast, but don’t bag on other people’s code. Basically, because you don’t know the constraints that that code was written under and I’ve walked in and seen things that I was like, Whoa, why on earth? Would you do it this way?

But approaching it. As you suggest Douglas with the error, an adjunct curiosity is far more constructive at improving the code, improving your job, improving the teams performance. Then tell me in, and especially if you’re a new person coming in and bagging on stuff, it’s just not. Not constructive, not helpful.

Douglas: It took me awhile to figure that out. It took some missteps to figure that one out.

Dan: Yeah,

Tyler: guilty. We [00:51:00] go. Where that, where that badge.

 so what’s your, I noticed that you started a consulting company briefly went over to the post on it. Would you recommend, I guess, in what context would you recommend that people go and start their own companies as, you know, as far as consulting companies go being that you do, bespoke or custom software or websites for other people who like who is the, Who’s the right, type of developer to go into that.

And at what experience level do you think they might be most successful?

Dan: Great, great question. So, you know, I would say that the first thing you want to do when you’re thinking about this kind of thing is to start your own company is to be aware of your risk tolerance. And take steps to minimize the impact it’s going to have.

Right. So that includes savings cutting down on your costs, if you can. I think that also makes it more of a good option for people with either spouses that have jobs [00:52:00] or, you know, single people with like low monthly incomes, or no, sorry, low monthly expenses. I think that’s just part of. The risk, right?

Cause it’s just, you’re, you’re at a higher risk than you are if you go be an employee. but a friend of mine says that there’s and he’s been a contractor for years and years, and I’m going to kind of mix contractor and consulting, even though we can talk about why they’re a little bit different. and he said, you know, there’s always three parts to any job.

It’s finding the work, doing the work and getting paid for it. And when you’re a consultant, number one and number three become really, really important. Whereas when an employee, it tends to be number one, number three, get taken care of for you, or you can focus on one of those three, right? You’re a salesperson.

So you do the find the work, your accounts receivable. So you focus on getting paid, or you’re a developer. So you focus on doing the work. So I think that, Being a consultant is really good for giving you a broader perspective of how to do things. It makes you think [00:53:00] about what the market actually wants.

basically you’re interviewing for your job all the time, because it’s very easy to let consultants go, which I find keeps you really sharp and makes you at least it makes me stay more in tune with the technology than I, in the tech world than I normally would. So, yeah. So I think you are interested in kind of stepping out from beyond being a programmer and you want the flexibility and you’re willing to accept the risk consulting lead.

Right? Like I did it for seven years in my thirties, in my twenties and thirties, and was able to take lots of time off and it feels really good to fire a client. If you’re like, Hey, this is not the right. Fit for us. that’s really freeing. It’s scary too. but I think it’s, it’s because of the way developers are and the demand that we have.

I think it’s a really good thing to do. I wouldn’t start out after from a bootcamp and go [00:54:00] be a contractor. I think getting, some expertise. Around other developers for a couple of years is a good start. And then also we’ll get you more ingrained in the community. I actually have a post, a blog post called of woodworking alone, where I talk about some of the difficulties, if you’re like a sole technical person.

And if you’re a solo consultant, that’s really what you’re going to have. Right. You’re not gonna have any other people working on the same projects necessarily, and that’s not a great place to be when you’re kind of trying to form your good habits.

Tyler: Awesome. That’s great.

Douglas: We agree with that jeans. Oh man. I was going to say that the, the, the idea we tell people that we, you know, when we’re trying to get, when we get into placement with them, that we don’t want them to go to be the only developer.

And I’ve had a mentee of mine who made that mistake, where they, he wasn’t the only developer, but they expected him to work on all this [00:55:00] stuff alone. So, again, it’s kind of in a silo and it did it and work out well for him. He was more junior and, and I had to have that talk with them. Like, let’s sit down and have a talk about, you know, it’s, you failed at this, but it wasn’t your failure.

It was actually a failure. Of the people that hired you because you didn’t hide anything from them, they probably saw your re I mean, I’m fairly certain, they saw his resume and, and, you know, they, they knew that this person was, it was like a senior developer who had taken in solution entire, project by, by themselves.

And, and so that’s, that’s kind of the, the, The thing that I think we’re getting out of here, is that be careful about doing that? Get some experience I’ve always said before you go freelance myself, I’ve said that. And I did the same thing. I just only did it for about, I ran my own company for about 16 months and said, Nope, not gonna do it again.

For awhile. I actually do have [00:56:00] intentions of going back out, but in a different way, when I do it, it’ll be a, it won’t be doing software custom software development for people when, when the next business gets up and running. but the, my risk tolerance was I thought was like nil. And then I went, I went out on my own and realized I actually had a much higher risk tolerance than I ever thought I did because, I mean, and it was just.

I don’t know the way that I kept work. I never went without work. I always had work. And if I didn’t, I would’ve lost my house. So it was, I don’t know, tribes having that, that behind you, having it in that fire under you, like, I better find the next job, but I also had to network. Right. That was another really important thing that if you’re brand new, if you’ve just started development, you don’t have the network.

When, when I went freelance and, And I had the, the Rob, I left by salary position for fizzled out on me earlier than, you know, much quicker than I thought it would. I called a friend up and said, Hey man, I’m in trouble. And he said, Hey, talk, call my boss [00:57:00] up right now. And I used to work with him with his boss back at another company I worked at, I had immediately had a new contract gig up and running.

And had worked within 12 hours of, of losing of losing. In fact, they came back and said, Hey, we were just kidding. And I’m like, I’m sorry, I already committed to a new trip. You told me I was, we were done. you can’t do that. If you really weren’t done. So I, I had new work within 12 hours of, of that, but dude, I’m gonna tell you something.

I don’t know if I ever want to do that again.

Dan: I mean, that’s actually a really, that might be a good, to speak to your, your question, Tyler. Like that might be a really good, test. Is,

Tyler: do you,

Dan: when you think about finding work, are you thinking about going to Upwork? And like some other place where you’re going to be one developer amongst so many others, some of whom are in places where they can get by on a lot less money than you can.

Or are you thinking about, Hey, here’s the 10 people I can email to say, Hey, I’m, I’m on the markets, [00:58:00] you know, do you have any work? Right. And that, that know you that want you, that would be thrilled to work with you for a little bit. And those are two totally different types of consulting, right? Like one is a recipe for misery in my mind.

and the other is, you know, a lot, a lot more pleasant and experience. I mean, I, when I was contracting basically eight weeks before my contract came up, or six weeks, I would just email everyone I knew, or the people I want to work with. Like, Hey, basically what Douglas was saying, Hey, I’m going to be on the market in six weeks.

Do you have any needs? And I was able to cobble that together, and that was way better than again, going to Craigslist back in the early two thousands or wherever you would go now. So

Tyler: that’s good to know.

Douglas: Yup. So we do have, we do have a dinner question that we kind of wanted to pose cause we saw the post on your blog.

and, and yeah, I actually subscribed to this a lot, but I thought maybe, maybe it’d be cool to hear you talk [00:59:00] about it, but I really enjoyed it. The best code is no code. That’s a really hard pill to swallow for some developers, but, I absolutely subscribe to that. So go for it, man.

Dan: Yeah. So, I mean, basically the premise is that again, this gets back to why we’re wired read software, right?

We don’t write software because it’s beautiful or because, you know, we want to impress people with our architecture diagrams or anything like that. We write software to solve business problems. And if you, every writer, every line of code you write is solving a problem, which is awesome, but it’s also incurring a cost and there’s a maintenance cost.

There’s a cognitive cost. there’s you know, costs of actually running things. so if you can solve a problem without, and the other, the other thing is that code, we tend to think of code is very malleable, right? Cause we’re in it. We can change it. We understand it. It’s our world. If you talk to anybody who doesn’t write software, [01:00:00] they think that code is like, Weird.

And like they will comport themselves to work around their code. I don’t know whether or sorry to work around applications that they have to write. So I’ve seen my wife do this where it’ll be something on a website and I’ll be like, well, no, we actually have to do it this way. Then she gets frustrated and angry that she has to do things a certain way.

And. So for both those reasons writing less code is good. One is you might be able to solve the problem without automating it, which means that people who aren’t developers can change that if things change in the future, which they pose will too, you don’t need a developer to write it. which means that it might be able to get done quicker, right?

Like the process might be able to, you solved quicker now. You can do manual stuff. You can use low code environments like Zapier and some of those other ones. I’ve seen people that were technically savvy, [01:01:00] but not developers. Build pretty interesting things with, with those kinds of solutions. A third option is to step back and wonder whether or not you actually need to do it at all.

Right. Lots of times. I think it’s called the Rhoda Abilene, was what, one of my bosses. Said once where you keep doing what you’re doing, because you’ve always done it, right. Inertia is a strong, powerful force. And I think that st you know, saying kind of a brash statement, like best code is no code is a good way for us to shake off that inertia and say, well, just because we’ve always done it this way, or because we thought we needed to do this six months ago when we expect this out, you know, do we still need to, if we do, you know, at the end of the day, I want to write code.

but that’s only in service of the larger business value.

Tyler: It’s like a, it’s like a, it’s like the extreme form of like YAG me. I kinda think of like, it’s like, it’s like, you don’t need you’re yanking Anita. Right. Or you don’t really need it. So, I liked [01:02:00] the phrase. Yeah,

Douglas: I think no. I mean, and, and it also, I kind of zeroed in on the like let’s piece things together that exist that have been tested, you know, like we teach our, you know, we show our students cause it’s part of teaching them how to use things outside of, You know, outside of just code that they write it, like bringing a library in or bringing in an external API.

We have an external API that we bring in that handles file upload. Right. That, that could be a real pain if you’re trying to do that with your own, you know, Java spring, boot application, which we could do. but. Making that part of your project where someone will handle that for you. And it’s really cheap to let them handle that for you and you don’t have to handle it.

it, that best code in that situation is usually the one where you don’t have to write the code to get the functionality you need. Yeah. And they could spit all the time. They want. On file uploads. Like if you, with this service, you file [01:03:00] upload and it’s a picture, they let you crop the picture. They let you do some manipulation.

You’re not going to put that in your project. And my in a junior is definitely not going to put that in their project. you know, when they’re trying to get ready for it, the end of our, our cohort. So it really is. where I would love to see someone write their own file, but you know, situation, I really want them to leverage technology.

And part of, I think our job is to, as you become more senior, I think that, that you, you kind of alluded to this Dan, before, as you get more senior, you kind of get this idea of. Should we really write the code to do this or not. And, and sometimes you have to really go, no, we shouldn’t write the code. And then that alludes to your, to this next thing that we talked about, which is the best code is no code.

I love it.

Dan: Yeah. I think there’s actually an interesting point in terms of, you know, what’s differentiating. What is, what is the differentiator for the pro the software you’re writing and Joel on software Joel, Spolsky [01:04:00] who I’ve followed for a lot of years. And I think he’s written some great posts, you know, said basically, if it’s not core to your business, you shouldn’t do it.

And I think about that in terms of applications as well. Like, you know, I’m sure that file upload is a key piece of functionality for whatever application you’re having your students. Right. But is it really going to be the thing that wows. The the, in the portfolio? No. Right. I mean, unless it’s, unless it’s a piece of open source software that is all about file upload, you just want it to work and be effective.

And so I do want to say that there were times in my career where I was. Feeling like a bit of a mechanic where I was kind of just tying stuff together. And I will say, I don’t think that’s very fun place to be, cause it’s a lot less creative. I feel like maybe now things either my perspective has shifted or, or the things that you can kind of plug in together are so much higher level.

They feel more powerful. But, so I definitely [01:05:00] understand the wine retro and file upload, I guess is what I’m saying, but I will say, you know, think is this going to differentiate what I’m building? If not, if there’s something out there, bring it in and get onto what is going to differentiate it

Douglas: for you.

Right. Or could you even write something that’s even close to this, this plugin solution in, you know, in the amount of time you have to work on this project. And I mean, in, in like the end of the cohort, like their capstone projects, they done, right. There’s, there’s no time to waste on, on writing a file upload component where, you know, you can just pull one in that’s free and it works and it’s great.

But then like maybe there are other places where, you know, if you’re writing a community, like if you’re trying to showcase what you can do in software development, and you’re trying to put like a community website together, maybe the chat portion, but the, the, A comments section of these, of posts.

That’s something you could talk about. Like I chose to use a file. This is [01:06:00] going to make them sound good. I chose to use a file upload component because I didn’t think I had enough time. Right. One, but we wrote the view because we thought this was a very core to our, to our project. We wrote the comments section.

Yeah. Like we wrote everything around the comments, in the, in the posts and how to attack, you know, how, how to match students together, you know, how to match people together and stuff like that. That’s the real, that’s the real stuff. Like you talked about the core functionality

Dan: of the product.

Douglas: Yup. Yup.

Tyler: So, we always like to ask this question, maybe heard it in some other, other ones, but what’s, what’s something we should have asked you that we ha that we missed, during our episode here.

Dan: Gosh. I mean, I was thinking about this, you already asked me kind of what my piece of advice to new developers would be. yeah. Another question you could ask is what’s the biggest mistake you’ve ever made? that’s always a fun one. yeah.

Tyler: All right. So what’s the biggest mistake you’ve ever

Douglas: made.

[01:07:00] Dan: So I was.

The senior technical person at a company that supported a sporting event that was on TV and the website that I was responsible for. It fell over during the sporting event. And, that was a pretty horrendous experience. and what I learned from that was always. Test your assumptions in his real possible way.

and I immediately took steps after that happened to make sure it never happened again. But, and I apologize to the client a couple of times the CEO apologize as well, but, that is, I mean, I’ve, I’ve written up. That experience for posterity. And when I wrote it up, like, and even now thinking about it, like my skin starts to crawl because it was just, so it was like 30 minutes of unpleasantness of me trying to troubleshoot this issue while you know, [01:08:00] the TV cameras is run and people were, you know, visiting the website during the event.

So that’s probably my biggest technical mistake.

Tyler: Sounds pretty stressful.

Douglas: Well, yeah, I can just say it makes my skin crawl thinking about being in that position.

Dan: It was no

Douglas: fun,

Dan: no fun.

Tyler: Well, that must’ve changed. what’s like, did you, did you, fundamentally change your thinking? like from a first principles, point of view, or did you only focus on that the, the, the assumptions portion, or did you learn more from that lesson?

Dan: I mean, I think, you know, it’s one of those things where there’s mistakes that you make that are like totally obvious and like boneheaded there’s other mistakes that you make that are kind of like systemic things where like a bunch of small things kind of combine, you know, snowball together. This was more like we knew what we should done and we [01:09:00] did do it.

And so, we up again, implementing some systems, both software and like process oriented to make sure that we would, we wouldn’t make this category of errors again, basically. So, and you know, it’s one of those things like it’s, it’s, easier to, I, it was interesting, cause this was a situation where this.

Thing was only televised, not that often, like once a year. And so it’s really hard to have a lot of, when you’re, when you’re in a process that happens regularly, it’s easier to like adjust and course correct. Whereas when the stakes are really high, it’s harder to do so. And so I think that this was situation where, more forethought on my part, should have happened.

And.

Sorry, my skin starting to roll now again.

Douglas: So maybe no, no, no, no, no. I think I kinda, yeah. [01:10:00] As I say, I get, I get it. It’s one of those where I think I’ve had, I’ve had a couple of, of things that not like on a television level, you know, where people were trying to get to the website. But one of these things where I really, I wrote the code.

Yeah. It worked, my database design seemed like it was good. And then a million rows hit. And everything came to a crawl, like stop. And it’s like, well, how would I’ve gotten, where would I would have come up with a million rows, but I’m going to promise you after, after it, after it fell over, there were a billion rows forever.

And the test database

Dan: totally.

Douglas: You know, where I’m coming from. I could

Dan: totally,

Tyler: totally. No, I think, I think,

yeah,

Douglas: put 10 in 10 million. Let’s go.

Tyler: No, I think it’s good because people can learn from other people’s experiences. Right. And we learned from our own experiences, probably the best, but if we can avoid.

I think, you know, a few people will probably avoid that in their career. And after listening to that and go, okay, if I know I’m supposed to do something [01:11:00] and it’s production code and it’s mission critical that I should probably do it, you know, that’s kind of what the takeaway I got from, From your, you know, if you could just put yourself, put yourself in, Dan shoes for a second and think of the amount of pressure and anxiety that must have pent up over 30 minutes while you’re frantically running scripts and, and looking every which way to try to fix a problem.

And, I think that’s a good thing to try to run away from, and, and learn from your experience, Dan. So thanks for sharing that.

Dan: Of course. Yeah. And, load testing. Yeah, for sure. If you are gonna have an event that is on television. Sure. You load tests as realistically as possible. So, to be more specific.

But, great question. That was a really insightful question folks.

Tyler: So, Dan, how can everyone connect with you and would you like to plug your book officially now since, I think this is a good time to time to do that. I S I saw that it’s going to be coming out, in a few months.

[01:12:00] Dan: Absolutely. Yes.

Thank you very much. So, yeah. So the book is available. You can preorder it right now on. Amazon Barnes and noble indie bound. Have you, if you go to letters to new developer.com, there is a book link and you can, click on it. And it has the table of contents and the, the cover and. links to all those places you can buy it.

I also would love if you just came to let her soon developer and fucked around like that. Listen, Tyler did and gave me feedback. You know, I love to hear. Hey, Dan you’re you’re, you’re, you’re crazy here, right? Like this is the wrong approach. I had someone actually write a letter or write an email to me today saying, Hey, I wasn’t sure what you quite meant.

Could you explain a little bit more and that kind of engagement, you know, I don’t know. I think anyone writes a book or has a blog, or has a podcast, you know, to, to make. Making a lot of money or to be famous, right? Like you’re doing it to help people. You’re doing it because it’s fun and interesting to you.

And when [01:13:00] you get feedback, that just makes you feel so good. So I also tweets, some more DSS, M O R E D S is my Twitter handle. And we’d love to connect with you there too.

Tyler: Awesome. Well, thank thanks again for your time. It was, it’s been a pleasure and, we’ve learned a lot tonight and, it’s, it’s been fun to talk about so many different topics.

Dan: Yeah. Thank you.

Douglas: Yeah. Thanks.