Show Notes:
On today’s episode we cover several topics:
- Why this podcast exists for Software Developers
- The many things that devs have to focus on to survive
- Definition of Senior Dev
- Dark Matter Developers
- Computational Thinking Skills
- Construx Software Development Ladder
Transcript:
[00:00:00]
Tyler S. Lemke: [00:00:00] welcome to junior to senior dev where we talk about the mental models, myths, and makeup of becoming a junior, a senior. It’s just totally messed up. That’s awesome.
[00:00:11]
Douglas Hirsh: [00:00:11] Cut. Restart. Get to do it again.
[00:00:14]
Tyler S. Lemke: [00:00:14] All right. Let me try it. I’ll just, I’ll just rip something. You know what? This would actually be pretty fun if we just like make, like every time we make up a new headline, every time we introduced the, it’s just like some riff.
[00:00:23] It’s like, where are we? Talk about whatever.
Um. Welcome to junior to senior developer where we talk about the myths, mental models and makeup of going from a junior to senior developer. I’m Tyler Lemke
[00:00:36]
Douglas Hirsh: [00:00:36] and I’m Douglas Hirsch,
[00:00:38]
Tyler S. Lemke: [00:00:38] and we’re here to,
um, we’re here immense. The, the illness that is going around.
[00:00:44] It’s, it’s funny that we started this thing,
um, now we’ve been talking about it for, I feel like we’ve been talking about it for several months now. Has it been a couple of months?
[00:00:53]
Douglas Hirsh: [00:00:53] Yeah. No, it’s been, it’s been a couple of months. And just getting us nailed down,
um, to, to recording has been, has been an interesting feat.
[00:01:01] So,
uh, a message to everyone out there and to ourselves. The, the biggest hurdle. Is actually hitting the record button. If you’re ever trying to start to do something which includes screencasting on YouTube or trying to make a podcast, you will, you will say, what if until you’re dead, if you don’t, just hit the button and go.
[00:01:21]
Tyler S. Lemke: [00:01:21] Well, yeah. And if we forget to hit the a backup record button for our video,
um. That would help.
[00:01:29]
Douglas Hirsh: [00:01:29] Yeah, we did. We did record an entire hour and 45 minute episode of this that we did lose, so we learned some lessons from that. We learned what not to do next time
[00:01:37]
Tyler S. Lemke: [00:01:37] I have my audio, so if anyone wants just me talking to myself for an hour and 45 minutes, let’s let’s release that.
[00:01:46] It’s not as interesting.
Um, so why don’t you, why don’t you explain,
uh, why don’t you introduce yourself a little bit more,
uh, Douglas, and so the audience can get to know you on a deeper level.
[00:01:58]
Douglas Hirsh: [00:01:58] Sure, sure.
Um, first of all, like I said before, my name is Douglas Hirsch. Currently I am an instructor at a coding boot camp called Coda.
[00:02:08] Where we teach a full stack utilizing HTML, CSS, JavaScript on the front end, and Java my sequel spring on the back end. Also, I do bring about 18 years of experience. I’ve worked for various companies,
uh, sizes from the foreperson startup,
uh, all the way up to a major bank. So,
uh, that’s pretty much where I come from.
[00:02:38] What about you, Tyler?
[00:02:39]
Tyler S. Lemke: [00:02:39] Yeah, I’m, I’m a full set, you know, the loaded term, full stack,
um, dot net developer at a insurance company called Allstar financial group.
Um, I also teach for tech talent South, which is,
uh, a,
um, bootcamp. And we’re doing everything online just like you are a Douglas. So,
um, and I’ve been in professional developer for about three years or so.
[00:03:01] So I’m really excited to, I’m kind of in, I’m kind of in the middle of this thing, and I’ve been interested in knowing how to go from a junior to senior developer. So that was kind of, we both, we both are very interested in learning and how, how to grow and, and things like that. So when Douglas, and we actually connected what, like,
um, it was about two years ago, we connected, or is it,
um.
[00:03:22]Trying to remember,
[00:03:23]
Douglas Hirsh: [00:03:23] I think, I think so. I think it was two years ago. Yeah. We can ask one of our, one of those, those rare networking events now, I don’t know if they’ll ever exist again, but one of those rare networking events that,
uh, uh, that we met at,
um,
[00:03:34]
Tyler S. Lemke: [00:03:34] yeah, yeah. We met at a geek meet,
uh, here in Dallas, and,
um, we, we kind of talked for a little bit and we didn’t hit it off.
[00:03:41] And then we met again. I geek me, what, like a year or two later? And,
um, just more recently and we hit, we hit it off and discovered that we have a lot of the same interests. And,
um, and I think this is going to be a lot of fun. So we’re gonna. So today I wanted to go over,
um, uh, we wanted to go over. A little bit about why this podcast exists and kind of see where this conversation takes us.
[00:04:04] But I think, I think one of the major things is, is when you first get out the door. As a developer, right? When you hit, when you hit the ground running and you have that first job,
um, there is a lot to think about, right? There are frameworks. There are the language. There’s,
um, the soft skills. There’s a million different things that you can think about and you don’t really know which one to put all of your,
um, to put your energy towards.
[00:04:31]
Um. What have, how many people have you seen get overwhelmed by that Douglas as you, as you’ve taught, and,
um, been a mentor over the years?
[00:04:41]
Douglas Hirsh: [00:04:41] I believe everyone gets overwhelmed by that. So the problem is, is that there’s, there’s everything out there, right?
Um. You know, you can go as far down the rabbit hole in any subject that you want to go down.
[00:04:54]
Uh, you know, thinking back, if you even think about like our version control, how does get work, you could get lost and how does get work? And probably just choose, Oh, I don’t, I can’t understand how this thing works, so I’m not going to write code. You know, cause I can’t even figure out how the thing works that I store the code in, which by the way, it’s very complicated.
[00:05:15] So I wouldn’t, I wouldn’t want it to go down that rabbit hole. I just know that my code is. Fairly safe in there.
[00:05:22]
Tyler S. Lemke: [00:05:22] That’s so funny. Actually. I just did a lunch and learn on get, and I was like, that was one of the first things I said was like, it very complicated.
Um, which is what I’ve, it’s so true.
Uh, so when people say, Oh, it’s easy to it, you know, that’s, that’s one big red flag right there is when people say something’s easy,
um, it’s probably cause they don’t remember how hard it was when they first started.
[00:05:44]
Douglas Hirsh: [00:05:44] To learn it. Yeah. Yeah. And the other thing that brings me to is that in, in learning software development, what I have to remind people of when you know, when I’m teaching, is that we do have some foundations right now in encode up, and I believe pretty much in any bootcamp out there, they’re going to start with, with.
[00:06:06] They’re going to start showing people HTML and CSS. The reason for that is because it doesn’t take as much,
uh, programming knowledge to be able to create,
uh, HTML elements on a webpage. It’s not as as difficult, so it’s more declarative. We’re not actually saying. Where to put the text in that element or where to put,
uh, or how to draw the font on the screen.
[00:06:36] It’s a very declarative markup language that you can use that gives people just a little bit of dipping their toe into the, into the waters of, of having to use a proper syntax. In order to get something to happen on their computer. So it’s very, it’s very visual and,
um, it is very,
uh, uh, forgiving, I should say.
[00:06:56] You know, it’s not as, as,
uh, difficult as getting into your first programming language, but then after you kind of get that under your belt a bit. Even before you get into frameworks and languages and design patterns and all this other stuff, the, the,
um, uh, I guess the next most important thing after you kind of get an understanding of, of syntax and how to edit a file and all that stuff, which is what HTML gives you.
[00:07:23] And even CSS to a certain extent, still gives you that experience is a, is a language, right? Pick a language. It typically,
um. The pattern that I’ve seen in a couple of bootcamps that I’ve taught in is that the next step is JavaScript, because that’s what runs right alongside the HTML NCSS. It’s what lets us modify pages on the, in the web browser itself.
[00:07:47] So we kind of introduce students to the,
uh, to that language, should try to get them acclimated.
Uh, into patterns of how a language works. So we teach them about. Instructions. We teach them how to assign variables. We teach about if statements. So logic. We teach them about looping. So these are major constructs that if you can master those in JavaScript, you could take that into other languages.
[00:08:17] It really comes down to mastering the patterns of, of programming. And I’m not not talking about design patterns here. I’m talking about. Just I’d give you a problem to solve and how do I write code to solve that problem? Not necessarily a design pattern itself, but when do I bring a do wild loop then versus a four loop versus even doing a four each?
[00:08:40] Is there a reason why I would do one or the other? You know? And that takes time. It takes a little bit of time of taking students through to get that, to get that knowledge. So yeah. You know, talking about all the things to worry about. There’s a lot of them out there, but the main thing and the reason why I th I, I firmly believe in coding boot camps is that we narrow, we narrow the surface area down to a very exact surface area so that you don’t get lost in all of those things.
[00:09:11] Trying to get ready to try to go get a job right
[00:09:16]
Tyler S. Lemke: [00:09:16] now that’s, that’s a great point, I think to bring this to more of a. Probably what our ideal audiences is. I think one of the, one of the things that I wish I would have learned,
um, earlier on was not to,
um, especially if you’re like, if you’re brand new and you just lost your job potentially because of the illness going around,
um.
[00:09:39]Give me, give me your feedback on this. Douglas. I personally think a lot of people chase, chase brand new. They chase bright and shiny instead of doubling down on the language area now,
um, because they’re like, Oh, I already know this language. I’m going to go jumped on XYZ and I’m gonna go jump on XYZ. I don’t, I don’t know if it’s,
um, I don’t know if it’s necessarily impressive for when people know 20 different languages when they’ve only been coding for like a year or two.
[00:10:01] Like, I think it’s more impressive to be like, Oh, you built something. A more complex or you understand,
um, you understand this ecosystem really well. What are you thoughts on that?
[00:10:12]
Douglas Hirsh: [00:10:12] So I agree with that, that that actually makes a lot of sense. Because remember what I was saying before. If you master the foundations in a language, it’s much easier to take those foundations, the recognition of those problems that you’re trying to solve and solve them in other languages.
[00:10:30] But again, remember, like I said before, it takes time. Of, of solving those problems in one language, to learn the patterns, to learn what you need to look for in the other languages, to learn what questions to ask about the other language that you would try to go into. So I, I do firmly believe that you have to stick with a language for a bit.
[00:10:53]
Uh, if it’s your first language, you need to learn it really well, solve a lot of problems with it, because that’s going to teach you,
uh, that’s going to teach you something called computational thinking, which is what you need in every language.
[00:11:07]
Tyler S. Lemke: [00:11:07] No. Yeah. I think that’s, yeah.
Um, can you touch more on, I think we talked about this before.
[00:11:13] What is computational thinking?
[00:11:17]
Douglas Hirsh: [00:11:17] So the idea of computational thinking is about. Breaking a problem down. So it really comes down to this breaking a problem down,
uh, looking at all the different patterns that come out of breaking that problem down. So what tools do I need to use in order to solve each of those broken down problems.
[00:11:37] Pattern recognition. Then from there it turns into, can I abstract anything? So what that means is can I make functions to solve those problems, those little problems, and then string them all together. And then the fourth step is implementation. So actually. String together, all of those functions and abstractions that you put together to try to solve the problem.
[00:12:00] Now, I made that sound, I believe I made that sound a little more complicated than I intended on it sounding. But what it really comes down to is breaking the problem into little pieces, remembering that you’ve seen those little problems before and then implementing solutions to the little problems. And you may have ways of doing that, that you’ve already done it.
[00:12:23] You should use those ways that you’ve already used to, that you’ve already done it.
[00:12:27]
Tyler S. Lemke: [00:12:27] So it sounds a lot like the dry principle, right? Like don’t repeat yourself.
Um, and it sounds like a fall is kind of, it helps follow some of those patterns with computational thinking.
Um, is the, is the purpose behind it?
[00:12:39]
Um, too. Have,
um, better softwares or is it to help people not get bogged down in, in the complex,
uh, overwhelmed by complexities of, of a particular task? Or is it to help with,
um, uh, requirements.
[00:12:53]
Douglas Hirsh: [00:12:53] It’s, I mean, as far as that’s concerned, as far as computational thinking, it is just that that is the spark, right?
[00:12:59] So we have this, what I mean by that is through existence, right? Growing up, before you’ve ever touched computer code, you’ve always had this way of, I think to yourself, I need to go make a peanut butter and jelly sandwich cause I’m hungry. Right, and you just go to the kitchen, grab the bread out of the bread box.
[00:13:20] She grabbed the peanut butter and jelly and you grab a knife and you do all this spreading, and you have a peanut butter and jelly sandwich. You don’t even remember how you did it. Okay. The computational thinking is just a different way of coming at problems. Instead of, instead of just going through and going through the motions, you computational thinking, you’ll say, Oh, I, I’m kind of hungry.
[00:13:42] I’m going to need a peanut. I’m going to make a peanut butter and jelly sandwich. So here’s the problem. I’m sitting at my computer on a podcast right now. The peanut butter and jelly is sitting in the cabinet, you know? So we’re going to break the problem down, right? Peanut butter and jelly is sitting in the pantry.
[00:13:58] Bread is sitting in the bread box, a knife, a city in the drawer. I need to now figure out a path to get myself from my front of my computer. You know it, go and get that stuff, you know, one at a time, open a door, you know? So it’s, it’s breaking the problem down in these little problems that, that if you were to try to write robotics software to solve those problems, you would understand what I’m talking about with why we would have to break those down.
[00:14:25] Because a robot doesn’t know how to, how to navigate and get stuff. You have to explain to it what everything is. At least once and then where everything is and where it is and all that stuff. But I mean, the, the idea of computational thinking is, is that that leap from just living our lives inside our body to trying to create a plan of attack for how to solve a task,
[00:14:52]
Tyler S. Lemke: [00:14:52] right?
[00:14:52] So it’s kind of like, it’s kind of like being very explicit with,
um. Our intentions and what we want want our software to do.
[00:15:03]
Douglas Hirsh: [00:15:03] Right. So that is, that’s kind of the thing is it’s, it’s just being very explicit. It’s that, but it’s learning how to be very explicit. Cause that’s not a skill that I see people,
uh. People don’t just come into the bootcamp with that skill, right? They have to learn that because we’ve learned growing up or going through life, and there was a time before I ever wrote code where I didn’t think about like, how does this break down and do what I can write code to do it with?
[00:15:36]
Um. You know there’s there is that that point in time where you have to make that shift in order to write software. We can’t just go, I want the software to figure out what I want the software to do. Right? That’s that Dilbert cartoon. Love to send that out. But you know, the Dilbert cartoon where, where the,
uh, the, the, I think it’s the manager or the project manager or something where they’re saying, they’re asking Dilbert to,
uh, to create a piece of software form and Dilbert’s like, well, you need to tell me what you want it to do.
[00:16:05] And they’re like, well, we don’t know what we want it to do. Will you tell us what, what? And he’s like, no, I can’t. And at the end it says something along the lines of, or the, the person, the, the,
uh. Project managers saying something like, well, Kate, you write a piece of software to tell us what we want it to do.
[00:16:20] Right? So, I mean, the thing is, is that you have to get to the point where,
uh, as a developer, you go from, from this, this experiencing life through what I have to do to get something done, to how do I tell something that doesn’t know anything to do this?
[00:16:37]
Tyler S. Lemke: [00:16:37] Right. Exactly. Yeah. That’s, and that’s, that’s requires a completely different mindset.
[00:16:42] So, yeah.
Um, the, you know, our first, our first recording, we, we, we mentioned something about, I missed it. Something about how there’s a lot of developers out there that we need to help.
Um, that aren’t the, aren’t necessarily the,
um, I’m going to go home and the home and code for four hours a day. So I code, you know, 60 to 70 hours a week.
[00:17:03]
Um, these are the, you know, clock in, clock out developers and there’s a whole spectrum, right? You might be on the spectrum, you might be like,
um, I, you know, I might, I might be okay working on a side project for an hour a day, but, you know, the rest of the day I have, you know, I have a family and,
um, I have other interests that I want to focus on.
[00:17:18] And you brought up this article.
Um, from Scott Hanselman,
um, who’s a developer from Microsoft.
Um, he has a,
uh, uh, he has a podcast as well, but he talks about,
uh, dark, dark matter developers. Can you,
uh, can you talk a little bit about
[00:17:31]
Douglas Hirsh: [00:17:31] that? Right. So what, what that really means, what dark matter developers mean is that it.
[00:17:39] Those are the developers that are fine with going to work and doing their job and they get the job done right. We’re not talking about people who don’t get the job done. These people, they, that’s most of people out there. They’re, they’re making the world move by writing software. And then you have these other developers, kind of like us.
[00:17:59] We’re talking about, we’re making a podcast right now, so we’re producing content and other people out there who have made YouTube videos, they’ve made content, they make courses. They’re, they’re not just satisfied with, with going to work every day. Those people are seen. You see those people, but your developers that go to work at eight in the morning and they leave at five o’clock and they got their work done.
[00:18:26] Those are, those are unseen, or they’re the dark matter of the development industry and they’re. You know, all developers who are in the field are very much needed. Whether they are out there talking about what they’re doing, or they just go to work and do what they want to do and go home at night and spend time with their family and don’t worry about coding at that point.
[00:18:47]
Tyler S. Lemke: [00:18:47] So there’s these dark matter developers. They can either be, they’re on a spectrum and they can just be like, I clock out at five Oh one like you mentioned in the article. Or they just, they work really hard and they’re not, they’re not necessarily in the limelight. Right? They’re not, they’re not someone that you’re ever, ever going to see.
[00:19:02] They have, you know, they might not even have a LinkedIn. They might not have a blog. They might not have anything, but they, they’re, they’re, they’re good at what they do and they get their job done.
[00:19:12]
Douglas Hirsh: [00:19:12] And they’re very important. And I would say even even to the extent I’ve seen more of you out there than I’ve seen me out there, and I’ve been that dark matter developer.
[00:19:21] Now I go home at night when I was younger and before I had a family.
Uh, and all I had to do was go home at night and sit and stare at the walls or watch TV. And I would, I would actually choose to work on code instead of watching television.
Um. I don’t do a lot of TV watching, although I did just kind of pull down the Picard series, the whole season of it over the past few days.
[00:19:44] Cause that’s awesome. And yeah, I’m a star Trek fan.
Um, and Picard. Yup.
Uh, so I probably just made a bunch of people mad at me. That’s okay.
Uh, but yeah, so I would go home at night and experiment with things and keep trying to be better at what I was doing, but I was never out there trying to talk about stuff I had done at work or, or, you know, putting out YouTube videos.
[00:20:07] And, and that kind of stuff. And I don’t, I don’t particularly know why.
Um, I do know that early on in my career,
uh, it, w YouTube didn’t exist, so I couldn’t have done that. We barely had the ability to download streaming audio. When I first started,
uh, writing code, and that was a professionally, professionally, I’ve been doing it for about 18 years, but I started writing code when I was 12, so,
uh, I’m 38 now.
[00:20:35] I don’t care about sharing my age. Everyone can know it. It’s fine.
Um, but I mean, it’s, I, I’ve been doing it for a long time.
[00:20:45] Tyler, I forgot where it kind kinda had that moment there where I’m going somewhere with this and I just totally lost it. So come, come in and rescue me, dude.
[00:20:52]
Tyler S. Lemke: [00:20:52] So we were just talking about dark, dark matter developers and how you, you see, you see me out producing content and getting out there more than you, and you used to do this more often.
[00:21:04]
Um, and that you’ve been doing programming for 26 years now.
[00:21:08]
Douglas Hirsh: [00:21:08] Yeah. So there we go. Thank you. I just need it. Sometimes I need a little bit of help to get back on track. But the thing is, is that,
um, I just wasn’t, I was a dark matter developer. I went and did my work. Every, every group that I worked in,
uh, every time I left the company, they fought with me about leaving, which is good.
[00:21:25] That’s a good thing, right? If they, if they don’t want you to leave, that’s a, that’s a good thing.
Um. You know, I did my job. And,
uh, even one of the odd things that happened to me recently, I got a phone call from a company that I worked for.
Uh, I wrote some code eight years ago for this company. It was a payment system.
[00:21:43] And,
um, they called me up at,
uh, this one guy called me up and said,
uh, Hey, you know, we’re trying to,
uh, make a change to your, to your system. And I’m like, okay, well, it. It shouldn’t be that big of a deal. What’s up? And they were telling me that, that,
uh, I, the code I wrote eight years ago has just been running in production.
[00:22:04] No one’s ever had to touch it. And it’s not because they needed to touch it for any reason. It’s because it just kept running. And evidently when your code keeps running, there’s a chance that source code gets lost. If no one ever has to touch it, so they couldn’t find the source code to it because it had been running so long and no one ever had to do anything with it, that it kind of got lost in the hands that it switched through from throughout the years.
[00:22:28] It’s there. They have the code, it’s in their source control, but over eight years of no one’s touched it, they may have forgotten where they left it. So
[00:22:37]
Tyler S. Lemke: [00:22:37] that’s a good problem to have. And, and we actually, when we talked about this before, you mentioned we’re talking about TDD and, and,
um, uh, I think I talked about the, the book, the,
uh, the art of unit testing and how it’s, how it says that you should basically learn three things.
[00:22:50] You have to do three things if you’re going to be good at TDD, right? So for those who are thinking about getting into test, urban development, have heard about it, you basically have to know how to write unit tests.
Um. You have to know how to do tests first. And the third thing is you have to know how to design systems.
[00:23:05] So,
uh, Roy Oscher, I’ve says, don’t, if a pragmatic approach is not to learn all three, and I’ve tried to do all three at once and,
um, no, I’ve struggled a lot.
Um, so I’m trying to just do the work on the unit test part right now, but,
um, you’re, you brought that story up of how you had this software work for eight years that they didn’t have to touch.
[00:23:24] And,
um. And the reason why TDD is, can be so successful is because when you, your, your test driven development means writing unit or integration tests that you can run against your software every time you build it. Right? So it means that when you go and when you go to make changes to your software, you can typically find regressions or bugs in your software very quickly.
[00:23:49] Is that a good
[00:23:50]
Douglas Hirsh: [00:23:50] summary? And maybe we should rewind for a second a little bit, because people may be a little lost right now. So I brought that up to talk about,
uh, talk about the, the. You know, I’ve had, over the years, I’ve done my job. I’ve done it well enough that someone called me up eight years later saying, Hey man, your software has been so good that we’ve not had to touch it.
[00:24:11] But can we ask you some questions if you could remember anything about, you know, because we can’t find the source code to it. And,
um, uh, but the reason why the software was so stable, first of all, it was a payment system, right? It, it handled. It handled communications from the point of sale system,
uh, to a ACH provider, and also took commands from a text messaging,
uh, aggregation service.
[00:24:42] So the whole, the whole point of it was, I was the hub, right? And there’s all these spokes in the system.
Uh, the point was, was that it was a payment system that would allow our customers. At this retail fuel company to start a transaction at the pump. With text messaging. So this was before apps, before smartphones were very prevalent.
[00:25:08] This was when you couldn’t get insurance on an iPhone because they were so expensive compared to every other phone out there. So a lot of people still had regular phones. They didn’t have. They didn’t have smartphones. Now everyone has a smartphone, but back then they didn’t. So we wanted to be sure that the text messaging or the, the payment system was assessable to all of the customers for our stations.
[00:25:35] And,
um, so I had to handle text messages coming in. That was my input. My,
um, uh. What are the people that I had to talk to was an ACH provider to make sure that they were good on the transaction, about the start. And then, and then I had to let the point of, you know, the point of sale had to let me know that, that Hey, someone’s about to start one of these transactions using your system.
[00:25:56]
Uh, is that okay? Do they have, is this, is these identification credentials? Okay. From the pump, right. They would send me information that the person typed into the pump and I would have to send back whether it was good or not.
Um. All of that was done from the very first with test driven development, but I had a lot of experience already in designing systems.
[00:26:19] I knew how to architect a system. I had already written out the architecture for the system and used TDD in a way to basically help me test out all the layers in my system as I was putting it together. So that was where that’s kind of building up to, you were talking about test driven development cause we talked about this story at another time and, and
um, that, that was the big deal about this was that it was a very,
uh, it’s a very good case for test driven development because the reverence of creating a payment system, I had to be sure that that.
[00:26:54] Payment system. If someone did a transaction for 50 bucks that it was only going to take $50 out of their account. I had to prove that and not because the company I worked for asked me to prove that they fought with me about doing TDD, because back in that day we were dotnet shop and test driven development was not commonplace in the.net world.
[00:27:16] TDD was was considered kind of fringe. In those in those days, it was not baked into visual studio as well as it is now and stuff like that. So,
um. It was, it was definitely a a fight for me to get it done, even with something as, as critical as a payment system. But what I did is I basically, they told me how long I had and I just made it happen within the timeframe I worked, I worked lots of extra hours to make sure that that project had tests around it.
[00:27:49] But here’s the thing. After I did that, any changes that they asked for after our first initial revision of the system went out, it took me, it might’ve taken me maybe a day or two to write everything up and make sure that it was well tested. You know, I could, I could be really certain that it was okay before I let QA take a hold of it.
[00:28:13]
Um. And, and that got me in a little bit of trouble. So being able to, to give QA ado build in a few days because the, the other side of the coin, which was the point of sale, didn’t have test driven development behind them and had like a two or three week or a one month long test cycle in QA to make sure that they hadn’t broken anything.
[00:28:35] And so. Bye bye. Good friend. Pride friendly project manager was always real happy with me. Douglas has done and he’s just waiting on, on,
uh, on the point of sale team. Finally, the point of sale team gets angry with me, sends out an email to my boss, his boss, and all the bosses and says, I don’t think Douglas is testing his software before submitting it.
[00:28:58] And the cool thing about doing test driven development was that I was printing out a pretty good log of, of every test. Went out and ran the test, shipped out, just the output from the test, which were the test names and the test names were stuff that made sense that anybody could read and know what they were doing.
[00:29:18] And,
um. You know, I said, Hey, these hundred and 27 tests run perfectly. And,
um, this is everything being tested for the day.
Uh, every time I build everything, everything is being tested. Every time I build,
uh, these three tests were at it in the next, you know, for the last feature that was requested. If you can think of anything I need to,
uh.
[00:29:37]To add to this, please let me know. Reply all it. Never heard a thing back. And,
um, but, but that’s the thing. No one was expecting me to have like written software to test my software and it’s really hard to sell that. And I think even once I left, they didn’t pay attention to it. So,
um, yeah,
[00:29:58]
Tyler S. Lemke: [00:29:58] no, that, that makes a lot of sense.
[00:30:01]
Um. And I, I’m sorry, I shoved that, that story in there. I re, I really, we’re not gonna be able to compress down our conversation from, from last time and in the amount of time we have.
Um, obviously, but I think, I think that it gets to the point of, well, I wish I would’ve known as, as a junior, you know, starting,
um, even I guess I started as a software developer intern was,
um.
[00:30:26]What kind of the 80 20 of things, what do I need to focus on? What do I need to be good at?
Um, and,
uh.
[00:30:33]The, I’d hope to get to this in a future episode, but it kind of the, you know what, what is the definition of a junior developer meant developed mid-level developer and senior developer because. There’s really kind of an ad hoc approach to this, right? It’s more on seniority and feelings and all this other stuff.
[00:30:53] Like how in the past, because you’ve been in several different roles, how have you been able to identify what a senior developer even is?
[00:31:04]
Douglas Hirsh: [00:31:04] So I, that’s a really good question, Tyler.
Um. I’ve seen people who’ve only been in the field for three years get called a senior developer, and that is purely because a could be a few things, right?
[00:31:16] It could be, it could be salary, right? In order to give someone the salary that they’re asking for, you have to call them a senior developer. And they have proven that they have enough skills to even to have that name.
Um, but I’m going to say that there’s a few things. There’s a few. Criteria that I would use to come up with who is a senior developer.
[00:31:39] One is going to be the amount of time someone has spent doing software development. Because again, a lot of this comes down to pattern recognition, and unless you have spent time doing software development, you don’t have the experience to identify those patterns. And even the ones where you can look at it and see that, that that’s a freight train coming at you.
[00:32:03] You know, you know, just by someone says that that one sentence that seems like too, to another developer, that would be, Oh, that’s really easy to do. Let me get that done for you at two days. And then it turns into a five week project. Well, I’ve been through enough of those that when someone comes to me with that one liner, I know that that one liner is so loaded that I basically either one, convinced them they don’t want to do it, or two, we’re going to be spending a lot of money on this.
[00:32:31] Because let me give you the 15 questions that you have, not that you’ve not thought of. And if you can say that you want to think through these, let’s do it. But that’s part of experience. That’s what, that’s to me, that’s what makes us senior developer.
Um, the other piece of this too is, is like when someone does come to you with a problem, can you put a system together that’s going to survive the test of time?
[00:32:56]
Um, I was able to do that. Right. They, they, you know, that that one system I built, I was able to put a system together that lasted, I mean, it’s almost 10 years old. It’s an eight year old system. It’s, it’s one of the crazy thing is it’s as old as my oldest son.
[00:33:14]
Tyler S. Lemke: [00:33:14] That’s awesome.
[00:33:15]
Douglas Hirsh: [00:33:15] That code is close to the same age as my oldest son.
[00:33:19] In fact, it’s, that’s amazing. It’s, it might actually be older than my oldest son. So when they said that, I thought it was six years old and then he said, no, it had to, the guy said, no, that had to have been written eight years ago. Now that I think about it, my, my oldest son just turned eight. And I know I wrote that system before he was born.
[00:33:39] So, I mean, so the thing is, is, is knowing, knowing the questions to ask about the code, not just of the people that are asking you to do the things, but knowing how to say, this code has to run forever. What do I have to do to make code run forever? Right? That’s, those are really hard questions to ask, and it’s not something that I would ask someone who’s a junior to ever think about.
[00:34:03] But maybe if they were working with me, I could, I could impart on them the knowledge of I’m doing this because I need to be sure that the code handles this and the situation. So it doesn’t just die. Right.
[00:34:15]
Tyler S. Lemke: [00:34:15] I think like part of, part of my goal for doing this as being able to impart and give to other people, like, look, here’s some strategies or,
um, um, cause obviously we can’t sit down with everyone.
[00:34:28] And you know, you can’t sit down with everyone and I can’t sit down with everyone and and try to unload all the knowledge that we’ve gained, but we can provide strategies and ideas and concepts that might help them to shortcut this gap because. You know, typically,
um, becoming a senior developer can be a five to 10 year process.
[00:34:49] Right? Have you seen developers, have you seen anyone take longer than 10 years before to become a senior developer? And it depends on the company too. You’re right. I know. It’s a weird title thing.
[00:35:00]
Douglas Hirsh: [00:35:00] Let me, let me put this out there. So one of the reasons that I’m going to go back to why I really like coding boot camps is that there’s a path.
[00:35:13] There’s a path that if you make it down that path, you become a junior developer, right? And so with a coding boot camp who has a proven track record, so I want to be real specific about that, not just Eddie coding bootcamp, but one with a proven track record of turning out really strong candidates.
Um.
[00:35:32]Are really strong junior developers. They know how to get you there within five months. And that could take you to get to,
uh, choosing a different path. Like going down the computer science path you come out of with a computer science degree, you may not have the applied skills to be able to write computer software, but a Cody bootcamp is preparing you to walk out the door and build websites immediately.
[00:35:56] Full-stack websites. That’s what they’re doing. That’s what we’re doing is trying to prepare people to do that. And then on top of that, what about, let’s see, what about,
um. You know from, from the point of of a junior developer coming out from that fi ours, the 20 week program. That’s actually the only way I would have ever gone back into teaching again was that I thought that 12 weeks was not long enough.
[00:36:25] And they came to me, the, the,
uh, this company reached out and said, Hey, do you want to interested? And I started investigating them. And when I found out that there were a 20 week long program, I was like, yeah, actually I’m really, I’m really interested in,
uh, in this cause I want to see how someone does this for fi, you know, with, as a five month program instead of a 12, 20 week program instead of a 12 week program.
[00:36:48] And so. You know, there’s a path in five months, we get someone to where they’re prepared to go interview and interview at companies like, like,
uh, um, cognizant or, or USAA, those are hiring partners of ours. This is strong, right? And we, we could produce them to do that in five months. And so what that tells me is you don’t need four years to do it.
[00:37:18]
Um, you don’t need, I know some people that taught themselves, and in the era, in today’s era that they took two or three years to teach themselves. You don’t need to take two or three years to teach yourself. You can get the basis in five months. But what, so that takes me on even further right. We said five to 10 years to become a senior level developer, but my question is, could you get exposed to things in three years if we could take what it takes to get into software development and get you exactly what you need in five months.
[00:37:59] To become a junior software developer, could we, in three to five years, get you the information that you need and experience that you need to become a senior level developer, like the exact path to becoming a senior level developer?
[00:38:17]
Tyler S. Lemke: [00:38:17] Yeah, I think that’s, that’s a great question,
um, that you have there. And I think that’s totally a possibility.
[00:38:22] And I think that,
um. Part, there’s, there’s a few different, there’s a few different,
um, gotchas that get on our way. I think. So one of them is, if you’re not at the right type of company, I don’t know if that’s.
Um, that’s going to help you as much. I say this because I know of,
um, someone here in Dallas.
Uh, he’s now a lead at a company, and I think he only has three years of experience after going to have, granted he has a degree, but still at being a T a lead at,
uh, with three years of professional experience.
[00:38:53] That’s pretty darn fast. And I, he, I think he did that because he was a consultant.
Um, he was on a consultant, a consultancy, and he had a lot of exposure to different types of code. Whereas,
um, some companies you won’t get as much exposure. You’re just in maintenance mode or doing other things. Part, another part of it is you have to be motivated enough to learn.
[00:39:17]
Um. I guess this, this comes together as like, will your job give you enough mentoring and teaching to get you there? Or do you have to do a lot on the side and, and obtain other mentors? I think this is kind of the, you have to know where you’re at right now and what type of company and how you’re going to get, be successful, shortcutting this process however you can.
[00:39:37]
Douglas Hirsh: [00:39:37] So I will say that most of the companies I worked at, I had to fight right to, to,
uh. No one told me, Douglas, should you go learn this or do you need to go learn that or go learn this, or,
uh, you know, or figure out how to design this kind of system. It was mainly that I ran into problems and. I, it felt really bad when I did something that caused a problem and I didn’t want to do that again.
[00:40:01] So me and Google had a conversation about how do I not suck as a software developer who was a very specific query,
uh, into Google and a bunch of stuff comes back like 7 million results. And,
um, you know, it’s like, Oh, okay, well, there’s a lot of reading to do and I don’t know which thing to jump into first, but let’s go ahead and start pulling in podcasts that showed up from that query and pull in,
um.
[00:40:23]You know, let’s just start trying to pull some information in so I can hear new things and know what to go look into. And that was the long road, right? That was the, I don’t know, the path. No one that knew the path was helping me with trying to figure it out. I was self-taught from a very young age, but didn’t mean that, that I had,
um.
[00:40:42]The, the, the professional development experience was there when I first got into the field. I mean, for crying out loud,
uh, my first, my first professional job that I had, so my first corporate programming gig where I wasn’t actually working on the computers that I was programming on.
Um, uh, they,
uh, I checked in changes that broke the build.
[00:41:05] I mean that was, I actually, you know, I, I, I was going to go to lunch that day and,
uh, I got up to go to lunch and just check my code in cause I didn’t want to lose it. And I didn’t think about the fact that I checked in like invalid syntax and that, that while I was gone, people might actually have problems with that.
[00:41:22] So I get back. And the way that I was taught my lesson was that,
uh, I found candy sitting on my,
uh, I found candy sitting on my desk. And,
uh, I was like, what’s this for? And my manager came over and said, Oh, it’s something sweet for you to chew on while I chew you out. I’m like, what did I do? And he’s like, you checked in breaking changes into the, into source control.
[00:41:44] You don’t want to do that because everyone downloaded your breaking changes and couldn’t build anymore. I was like, Oh. That makes sense. But I didn’t know that cause I’d only work with code on my own and not in a team. Right. So I mean it’s those, it’s those kinds of things where, where it was longer for me because we teach people from the start here about.
[00:42:06] About source control and checking stuff in and not breaking, not breaking the build. We have them on to get from a very early point in our, in our course. And right now they’re, they’re even creating their own, get organizations and, and,
uh, doing poll requests and all this stuff. And we’re, we’re, I think we’re like six going on six weeks into the program.
[00:42:27] So we’re, we’re really ramping them up. It’s the, it’s having someone that knows the path because if you don’t know the path. Then you’re going to spend a lot of time out there looking around, not knowing what you really need to know in order to get to the next level. So I think the question is, could you do it in less time?
[00:42:49] Are had someone taken more than 10 years? You always hear the story about someone who’s done the same year, 10 years in a row. Right? Who doesn’t have much more experience than, than just in that one domain that they’re in, or even just the way that they write code because no one’s made them go outside of their box.
[00:43:09] Well. No one was trying to force me outside of the box that I was, I was in. In fact, everyone would have been a lot happier if I had actually just stayed in the little box and done what I’ve done, what I was told, and not always tried to create waves by finding all the new stuff and, Hey, we should try this test driven development thing.
[00:43:28] It would be a lot better. We’d have much fewer bugs and you know, I would have been a lot less annoying if I had. If I had just gone with what everyone else was doing, but it was, I didn’t want to sock and I was tired of putting out software that had bugs in it. So I wanted to do things to prevent that from happening.
[00:43:50]
Tyler S. Lemke: [00:43:50] well, I
[00:43:50]
Douglas Hirsh: [00:43:50] think
[00:43:53]
Tyler S. Lemke: [00:43:53] there’s, there’s,
um,
[00:43:54]so I think one of the reasons, one of the things that we talked about before was there’s not, there’s. I, I’ve, I’ve run around, you mentioned that you haven’t run around very much content that talks about this.
Um, and I haven’t found very much either in the stuff that I have found is, is mostly con. It’s mostly densely contrary, concentrated and in the thoughts of wander or a few people.
[00:44:16] And so,
um, we’re wanting to, or wanting to interview people.
Um, and bring on various different ideas so that you’re not just, we’re not stuck in a,
um, echo chamber. Right. So what type of people do you think will be able, what type of thing people do you think we’ll be able to bring on? I have some ideas, but,
um, let’s not name names, but what’s the type of people do you think will be valuable to bring on an interview?
[00:44:40]
Um, are you thinking, would recruiters be useful to bring on? Would,
um. Hiring managers would, senior level dabs, would VPs, would, CEOs, who are the type of people that are going to help,
um, help with this process and help give us ideas of, of how people can move from junior to senior or from mid to senior faster.
[00:45:00]
Douglas Hirsh: [00:45:00] That’s a really good question. You’ll hear me say that a lot cause you do ask a lot of good questions.
Um. The, the thing about this is that I believe that all of those people have something to do with what we’re trying to do. So there are different facets to a senior level developer that is not just, can I crank code.
[00:45:24] Right. If it were, then what I would tell you is that the only people we need to worry about bringing on are senior, senior developers and and lead developers. Cause they’re the ones that are going to help us try to get people down the path. But it would be really cool to actually hear from. CEO’s and CIO, CIO, or CTO, actually more likely CTOs.
[00:45:50] Right? You know, how do they view developers? What are, you know, from their point of view, how, how. You know, H how is it when developers interact with them? Because part of this is not just, and a lot of people think that when I go into software development, I can just get locked in the closet and they feed me pizza and caffeine and I give them out code, you know, like a, like a mushroom, basically.
[00:46:11] Right. And,
uh, um, it’s, it’s not like that. And it took me a lot of years to figure that out. But it, it, I could not just go and be in the closet and get fed caffeine and pizza and, and that’s going to, that’s not going to actually progress me down a career at all.
Um. But it would be cool to talk to people at different levels that do have interaction with developers.
[00:46:34] Now, that’s an important aspect, right? So hiring managers would be good, but you never know. You could have a startup where the CTO is interacting directly with developers or a lead developer that’s interacting with developers and, and so I think that that. Everyone is good to hear from. So I have really no,
uh, no bias against who we could talk to about stuff.
[00:46:57] The only thing that I have, or that I would say is I want to be sure that they’ve, they’ve got some contact with a developer, you know, that they can say from their side how they view things. And,
uh, for like people in the, in on the business side. Like I would love for developers to understand that we work for a business.
[00:47:19] Right. Right. And that business has to make money. And the only reason why we’re around is because we actually make more money for the business than it costs them to have us.
[00:47:30]
Tyler S. Lemke: [00:47:30] Yeah. That’s called beginning.
[00:47:33]
Douglas Hirsh: [00:47:33] Right. And when it, when it costs more to have us, then they let us go.
[00:47:38]
Tyler S. Lemke: [00:47:38] Exactly.
[00:47:39]
Douglas Hirsh: [00:47:39] So that’s, that’s the thing is that, that we have to understand, this is the thing that I wish I could go and make myself really understand when I first got into the field.
[00:47:50]
Um, is that really knowledge of the business that you’re going into to write code for is the most important thing you can have to understand when someone comes to you with a problem from the business. Because all problems come from the business. Right? They’re trying to solve a problem in the business side of things.
[00:48:09] Sometimes people get stuck. I’ve heard some horror stories about, about, Oh, we have a perfectly working infrastructure, but we want to go to a containerized infrastructure. So we need to convert all of our software to work within Docker containers and, and,
uh, uh, be deployed with Coubernetties and, and,
uh, you know, all this, you know, and then people start a multimillion dollar project to do all that when actually everything worked just fine.
[00:48:32] Right. You know,
[00:48:34]
Tyler S. Lemke: [00:48:34] you want some underlying ways that it makes sense, like not just because it’s, it’s bright and shiny. Right?
[00:48:40]
Douglas Hirsh: [00:48:40] It’s cool. Right. I’ve also seen,
um, I’ve also experienced personally where I talked to a company where,
uh, they, they, it’s a really cool company. It’s a startup and they’re doing some really cool research in, in,
um, uh.
[00:48:53]Actually, I’m not sure how much I could talk about it, but it’s a, it’s a medical device company. And,
um, I should sign some documentation before I talked to them that
[00:49:02]
Tyler S. Lemke: [00:49:02] out the last sentence there.
[00:49:04]
Douglas Hirsh: [00:49:04] No, no, no, it’s fine. I, the one’s going to know based on what I said, but the thing is, is that they,
uh, their senior developer wanted to learn, go.
[00:49:14] And so their infrastructure was there, their microservices were written and go and no one else does go. And that guy left. And so bright shiny was go and the business paid this person to write this code, and now they have to figure out how to get other people to work on this code. Where if I were running the project, I would have said, no, we don’t need to write this and go.
[00:49:41] We need to write it. And something where I can find people. More people because you may not even be the only person ever working on this. I need to be sure I can find people at a decent rate. So I don’t want it to be like one to a hundred developers, you know? Cause that means that they’re going to, they’re going to be very expensive.
[00:50:01] You would have to explain to me why going to why working in NGO is going to be financially sound for me. Yeah, it’s, see, this comes from the last company that I was at. I was, I was actually the CTO, so I had to think about everything. And I also still did development even it was a startup. So I even did development and I was the CTO.
[00:50:22] So I had to think about money and I had to think about development. Right? And so that, that opens my eyes a lot too. But the thing is, is that what I’m trying to impart is that. We are, we are employed to help our employers make more money. And if we don’t do that, that’s, that’s the basis of our entire employment.
[00:50:45] Like for me,
um, I like teaching, but if I had no students, they wouldn’t have me as a teacher. The students are the ones paying my bills right now. Right. Right? So it’s always about where’s the money coming from to pay for you as the employee to do the work that you’re doing. And that’s the one thing I wish I could have imparted into myself when I was much younger.
[00:51:09] I might’ve been a lot less aggravated about things if I had realized that, yes, I want to be sure the code is stable. The only reason why I would ever fight about something is because of stability and cost savings from that stability, not from like, I really think it would be cool if we did. We did test driven development because I want less bugs, but less bugs will equal us having to spend a lot less money over time and that would have been a much better argument for me to have with people, or at least with people above me.
[00:51:39] Right. Yeah. I just don’t want to write, I don’t want bugs. Right,
[00:51:46]
Tyler S. Lemke: [00:51:46] right. So you have to, you have to. I, yeah. I think you brought up a good point. Like,
um, you really have to, something that I’ve learned in my career,
um. Shorter than yours, but,
um, is you have to be able to, if you can deliver what your boss wants you to deliver, you become valuable if you can’t deliver.
[00:52:03] And so there, there’s a lot of different components to that. There’s a cultural, there’s a cultural component of do you match? Does your strengths match the company’s culture? Right? And that, and,
um, we could go into nuance in that future episodes, but I think it’s a really important to know,
um. If your strengths match that company.
[00:52:21] So for example, if you’re at a startup,
um, and you don’t, if, if you’re not a 10 X dev, most startups want 10 X type devs, right? They want people who can crank out code as quickly as possible, and because they, they have to make money or they die, right?
Um, and. I’m not saying you have to be one, but that, that’s just a small example is like they, they want people who can deliver.
[00:52:46] So going to a startup as a junior developer, and I’ve talked to other senior,
um, senior developers about this, or at least one other, that I’m going to a startup as a junior developer, it’s like sink or swim a lot of the time. Because you, they don’t have time to train you. They don’t have time to teach you.
[00:53:02] They need to develop a software so that their company stays alive. So,
um, that might not, that might not be right for you either. So that’s something I’d like to discuss in the future is,
um, how, how you can, how your strengths can be used to make you, how you can use your strengths to leverage yourself to become a mid and then a senior developer.
[00:53:23]
Douglas Hirsh: [00:53:23] Yeah. No, I mean, that’s, that’s,
um, uh, I would say that, that, that is a very important point you brought up about the, the people that, you know, if you go with a startup,
uh, I actually have another episode idea for you, which is. Are there really 10 X developers?
[00:53:38]
Tyler S. Lemke: [00:53:38] Yeah.
[00:53:40]
Douglas Hirsh: [00:53:40] So that’s a, that’s another one that for another day.
[00:53:43] But,
uh, I do understand that there are people that can crank code out really fast. But again, if you don’t have all the facets of being a really good developer, which does it mean just able to crank the code out? You don’t need to. You need to,
um, be able to interact with the people and you need to be able to, to.
[00:54:01] Baked code based on what they’re saying. But if you crank code out really fast, that isn’t what they want because you didn’t want to talk to them because you wanted to stay in your closet and eat pizza and taking caffeine and churn out code lessons learned from my past.
Um, then then you know, you, you can get into trouble that way.
[00:54:20] Even if you can crank code out really fast. If it’s, like I said, if it’s not what people want, then they’re just, it’s going to be a problem.
[00:54:28]
Tyler S. Lemke: [00:54:28] Well, I wish I would’ve mentioned this earlier,
um, segue into another part is why, you know, why should people even care about this? I think, I think if anyone’s listening to this episode,
um, and you have people around you, you might be able to commence,
um, convince those around you,
uh, that there is an opportunity cost to not becoming a, a senior developer faster or having those skills.
[00:54:51] So right now with the illness that’s going around.
Um, and I keep saying that because YouTube will, do you monetize if we say the actual word.
Uh, but,
um, the illness going around,
um, if you are a strong, if you’re a strong junior developer, you probably have, you’re probably getting paid less, so it’s more likely for you to stick around.
[00:55:10]
Um, so it’s actually, you know, it can actually help you a lot just to stick around right now when in the,
uh, in. In the, the turmoil we’re all going through in the world. The other thing is, every year you don’t make, so typically as a, as a, let’s take a Texas for example.
Um, typically you, like, let’s say you start in Texas at $60,000 per year as a developer, which is a, it’s a reasonable starting salary.
[00:55:38]
Um. You could, you could be making 120,000 as a senior, as a senior level developer at some point. So the like, like you like the word Delta, right? The difference between those two numbers is 60,000 a year. So every single year you’re not making the extra 60,000 a year.
Um, if you were to just, if you were to just to think,
um, if you were to invest, just invest that, that different.
[00:56:03] So let’s say over three years you lost. Like $60,000 or a hundred thousand dollars by not becoming that developer faster. Let’s say you lost 10,000 a hundred thousand dollars over your career by not leveling up faster, and we won’t go into all the details of the years, but let’s say it’s a hundred thousand dollars if you invested that in your twenties.
[00:56:22] It’d be worth, I, it’d be worth millions of dollars at the, at the end of your career. So you’re literally forfeiting all this money by not leveling up faster. And you’re also,
um, potentially putting yourself in a precarious situation by not,
um, but not trying to skill up. So, and I mentioned this is because I was so worried.
[00:56:43]
Um, I actually started going to college when in 2013. And I stopped going because it was too expensive. I didn’t want to go into debt, and the school actually wasn’t that expensive and the amount of debt I would have taken on had I learned. Had I gone through school faster, I would have, I would have easily paid that back by tripling my income.
[00:57:02] So there’s a really important concept called opportunity costs, and you just have to realize that by not, by not doing something, you are giving up something else. Right? So by not becoming a senior dev faster, you’re giving up potential money and potential opportunities down the road.
[00:57:22]
Douglas Hirsh: [00:57:22] Wow, man, I hadn’t even thought of it that way.
[00:57:25] I know, I know about opportunity costs, but I had not put the two together.
Uh, as far as not making as much as you could make,
uh, at your full potential as a senior developer and looking at the Delta and then saying, Hey, I’m losing that money by not being, not getting to senior as fast as possible.
Um. But that is, again, that could be, that kind of gets into some people who get called senior developer just to get them into the company to pay them.
[00:57:52] You know? What it requires to get them in. They may not be an actual senior developer yet. Maybe they haven’t even had the experiences. Maybe they’re there five years in, but they, they’ve been in this one environment and they only know how one environment works and they’ve not seen a lot of different problems.
[00:58:09] So they don’t have a lot of good pattern recognition that we’ve talked about over the, over the years.
Um, so the, the thing that I would, I would think about is that it’s not just. It is financial is good. I mean, like I said,
um, I hadn’t even put those two together and I think about numbers a lot and I hadn’t even thought about that.
[00:58:29]
Um. But the, the other thing about this too is that,
uh, it’s the human aspect of it, of you want to do a good job, right? I’ve not met, okay, well I may have met one or two developers that were those type that said, I’ve just coming in in the, in the morning, I’m checking out at night. I will do whatever they tell me I have to do throughout the week and I’m done.
[00:58:50] Right.
[00:58:51]
Tyler S. Lemke: [00:58:51] But in the fact that they don’t care, they don’t care about the quality of their work. They don’t care about the quality of code are becoming better over time.
[00:58:58]
Douglas Hirsh: [00:58:58] Right, right. They’re not trying to become better. So they’re going to have the same year and less and less, they’re required. So unless they are put into positions by their manager that makes them grow, they literally could experience the same year of software development over and over and over again because they’re not trying.
[00:59:19] And,
um, that always that. That’s where you do get someone who’s been in that for five years and someone does say, Oh, I have to pay them as a senior developer because they have five years of experience, but they don’t have the other side.
Um, they don’t have the actual other side of it, which is you don’t want to go into a position that you don’t.
[00:59:38] That I won’t say that you’re not ready for cause I want to be careful about that. Right? I want people to stretch themselves. That’s the whole point of, of doing what we’re doing is we’re always stretching ourselves. But what I want to impart is that. You, you should, if you actually did get that senior developer job, but you’ve only been experiencing the same year over and over and over again, you may not be ready for how that company is going to rely on you.
[01:00:10] You may not be ready yet. And, and that’s, that’s where, that’s. That’s a risk and you might survive that. You might survive taking that leap, but that is always a risk. If you, if you were selling yourself as a senior level developer, but you haven’t really done the things, then you’ll make the money, but you might not be able to handle the job.
[01:00:32] And that’s why you have to always push yourself to try to get better and better at what you’re doing is, is that when you do get that opportunity to take that job, that you keep it.
[01:00:45]
Tyler S. Lemke: [01:00:45] Right. And so I think, I think he brought up a good point. I don’t know if you’re trying to allude to the fact that you might become a senior level developer within your own company and they might pay you more just to keep you there.
[01:00:55] Right? But, but now you’re in a precarious situation where you might not have the skills to pivot to another company. I think that’s really, I think that’s where the mastery comes in. I’m talking about the money from a. For like, obviously we’re all in it for, we’re all in working for the money. Otherwise you quit.
[01:01:12] Otherwise, like you’d quit where you’re doing it and go pursue what you actually like. Right. Unless you only like coding cause you could just get, do code for free, right? You could just go open, do open source and work on whatever you want. Like you wouldn’t have to be directed by someone if you didn’t care about the money.
[01:01:28] So.
Um, I think the money is, I don’t, not saying you’re not saying the money is important, but I think that it’s good to think of the money is important, mastery is important and you need,
um, and if it’s a motivation to help you, like you want to be, like, the way I think about it is I want to be paid commensurate with the value that I provide to kind of, like you mentioned before, cause if you’re not providing that value now, now that you’re going to be the person,
um.
[01:01:54]Like in the situation we’re in today, you might be that person that gets cut from a company because you’re not,
um, uh, you’re not, you’re not producing as much as another person. Right.
Um, and that’s, that’s a potential risk.
[01:02:07]
Douglas Hirsh: [01:02:07] Yeah. Yeah. And I wasn’t trying to discount, ha ha. I wasn’t trying to discount,
uh, the, the.
[01:02:15] The importance of of money, but the, the thing is, is that I also want to balance that with the skills that you’re going to need and not even necessarily in the same company, right? If there are people there, this is a valid tactic in our field, which is that I’ve been here for a few years. Let me put my feelers out and see if he was willing to hire me and promote me in that hiring.
[01:02:41]
Um, maybe you feel like you want to go work for a different company and see different things.
Um. And, and now you’re trying to interview it. You go in there and realize, Oh no, why, how, where did all these questions come from? I thought, I’ve been programming for all these years. I don’t understand anything.
[01:02:56] These people are saying, what is this? You know,
uh, or even worse, which is you get through their interviews, come in day one, and you’re really in over your head. And,
uh, you either just in time learning or you’re out the door, you know, it’s, it’s,
uh. It’s important. Both sides of that coin are very important.
[01:03:15] Yes, we’re doing it for the money. Money is not everything though, but we are. We are doing it for the money. And I mean, I say that because,
uh, I firmly believe that because I could go have gone and made more money as a software developer somewhere else than what I’m making as a teacher right now. I’m doing what is congruent with where I am right now.
[01:03:37] I still write some code. I’m actually, I was playing around with something using,
uh, uh, no JS and, and,
uh, soccer dyo was using WebSockets underneath to do some, to, to make up like a really cool student clicker,
uh, you know, where they could actually tell us what their status is.
Uh, in class, I was just playing around with it cause I wanted to go write code.
[01:03:56] So I’d go write code for fun and I go teach people to code for my living now. And,
uh, I actually kinda liked that for now. I’d say for now, I mean, there may come a time where I want to go, I want to like put the gear back on and go in full time and, and,
uh, design systems again and, and,
uh, you know, handle all that.
[01:04:16] But right now I want to, to bring people in,
um, into the field and that’s, that’s kind of, I’m taking less money to go do something that is congruent with who I am as opposed to doing it just for as much money as I can make right now. Right. So I think it’s important.
[01:04:35]
Tyler S. Lemke: [01:04:35] Yeah, exactly. And I think, I think the other thing is, if you’re just like, a lot of people say this and I agree with it, is if you’re just in software engineering for the money,
um, it’s hard to have that as the only motivator to keep you going with all of the different,
um, with all the different,
uh.
[01:04:50]Challenges we face as software developers. And so I would, I would caution,
um, that people find other motivators to help them besides just the money so that they don’t end up quitting early in their career.
[01:05:04]
Douglas Hirsh: [01:05:04] Yeah. I, I agree. And I still like it. I mean, I really, the first time I ever wrote hello world and C plus, plus, I never stopped writing code.
[01:05:14] I still haven’t stopped writing code. I just don’t do it for a living right now. And,
um, that, that kind of brings back that childhood wonder that I had back in the,
uh, uh. Back in the old days cause I just, you know, if I want to write some code, I’ll write it. If, you know, something that really brought my attention to that, and this is, this is kind of going way into the years here.
[01:05:34] I was talking to my dad and he used to write software too when he was, when he was younger. And,
um, he told me, you know, you asked me at one point when I was telling him I was thinking about changing careers and he asked me if I wrote software for fun anymore. And I said no. And he goes, yeah, that happens.
[01:05:48] You stop writing software for fun at one point. And he, he would know. I mean, he, he had a lot of years in software development before he, he stopped. And,
um, but that’s definitely a stage. And I think we’re, by going into teaching people how to write software, I’m kind of reverting that a little bit and bringing the interest back into writing software myself instead of doing it for a living, I just do it for free.
[01:06:13] Because I want to,
[01:06:15]
Tyler S. Lemke: [01:06:15] yeah, there’s,
um, that’s actually interesting. There’s, there’s a book,
um, that talks about,
uh, is it peak peak performance. I think,
um, they talk about how if you’re going to,
um, if you’re on the edge of, if you’re on the, at near the edge of burnout or really good thing to do is actually go and mentor other people.
[01:06:32] Right. Cause that’s kind of what you do all day long.
Um, you teach and then I’m also a mentor.
[01:06:37]
Douglas Hirsh: [01:06:37] Correct. It’s so it’s, it’s a, it’s a mix of lecturing. So the way that we work, it’s a big piece of lecturing. And then we do exercise. And during exercises, I do get to nudge people in the right direction, a bit, right.
[01:06:52]
Tyler S. Lemke: [01:06:52] Progress. But,
um, but mentorship can actually help you a lot with that. So,
um, that’s an idea. If you, if you feel burnt out right now, go and go and find, I found teaching, relaxing myself, so I really enjoy it.
Um. But we’re getting, we’re running out of time here. Was there any other,
uh, points that we didn’t cover so far that you’d like to cover?
[01:07:10] Douglas,
[01:07:12]
Douglas Hirsh: [01:07:12] I think for today’s, for today’s episode, I think that it’s, I think we’ve done great. I think we’ve covered a lot and I look forward to our next episode.
[01:07:23]
Tyler S. Lemke: [01:07:23] Yeah. So we’ll be doing these on a weekly basis and we hope to see you again here soon.
[01:07:31]
Douglas Hirsh: [01:07:31] Bye, bye.
