What We Discuss:

– Creating Software the Business Doesn’t Want

– How to Focus on What Your Boss Cares About

– Technical Debt

– What is a Business Domain?

– Company Culture

– Conway’s Law

– Question the Interviewers

Links:

https://juniortoseniordev.com/

https://agilemanifesto.org/

https://en.wikipedia.org/wiki/Conway%27s_law#:~:text=From%20Wikipedia%2C%20the%20free%20encyclopedia,introduced%20the%20idea%20in%201967.

https://xkcd.com/1205/

Hi, and welcome to another episode of the junior to senior developer podcast. I’m Douglas Hirsch, and I’m Tyler Lemke. And let’s get this show on the road. So Doug, what’s up, man. This is, uh, you know, we’ve had a, kind of a. Rocky start to, to a recording, but we’re getting, I think we’re getting the flow of things.

[00:00:23] I think we’re, we’ve had some great episodes out so far. So I think that we picked a topic today, I think is very pertinent to understand. Um, I’ve worded it in a different way than you have. Um, my, my, my take on it is like, what’s the most, what’s your, what’s your highest responsibility as a software developer, right?

[00:00:41] Or what is, um, what’s the thing you should be most concerned about? Um, but you put it in a different way. What was your, what was the way that you put up? Well, I tried to put it in a way that that really conveys it, but in a, in a kind of tongue and cheek kind of way, a little bit, but the business is your business.

[00:01:01] Is the way I put it, maybe the inflection was wrong, but what I’m trying to say is the business that you work for, how they’re doing, how the code you’re writing, uh, affects them is your business. And that’s a very real important principle. I think, to keep in mind when you’re writing code or you go to work as a developer, that something you’re doing.

[00:01:29] Has the ability to affect the company that you work for? That reminds me of the agile manifesto, right? What’s the,

[00:01:42] what’s the site it’s like from 2001 or whatever. Um, working software over comprehensive documentation. Um, individuals and interactions over processes and tools that kind of, that kind of reminds me of that same, um, in that same, uh, thing that if you don’t have software that actually, um, customer collaboration over contract negotiation, right.

[00:02:03] And I think it might fit there inside there is where if you don’t have software that actually fits the user’s needs, then you don’t have a job anymore. Right. Like if you don’t have a software that fits the user’s needs and this, we see this with startups, right? What’s the most important thing in the startup world.

[00:02:22] It might be pivoting if you can’t actually fit to a user’s needs, you’re going, unless you have a huge bunch of UVA, unless you have a ton of VC money you’re going to disappear. Right. You have to have a, you have to have an idea that, um, or you have to be trying to solve a problem that a lot of people are having a problem with.

[00:02:41] In order for your startup to work, there has to be like a, a problem and a value add that your pitcher, you know, you’re, you’re kind of helping someone through this problem that they’re, that they’re having. And, um, you know, I’ve worked at a couple of startups myself, and I kind of get the idea. And even if you have this really great product, um, If you have this really great product, the idea that people are just going to see that get the fact that you’re really helping them fix the problem.

[00:03:10] Is it a hundred percent guaranteed? I’ve seen some really cool startups that I thought really helped solve problems, but no one cared.

[00:03:22] right. So that’s proving, that’s kind of proving the, um, The, the, the proving the market, right? Kind of a, the fail fast mentality, or, um, lean startup where you’re proving that there’s three proving. There’s actually a need out there. I think that’s really interesting. Cause I think it’s so easy as a developer to go look, I got this really cool idea.

[00:03:41] I’m going to go build this little thing. Right. And the company, the business might not need it or want it. Right. But you’re like, you guys need this. And I think I’ve had that problem before, where I focused my optically on something that’s very minuscule of a problem versus solving, um, you know, a macro problem that exists within the business and that can really hurt, um, how you’re perceived as a developer.

[00:04:06] If you’re, if you’re focusing on the wrong solving the wrong problems with software. And I, I actually I’ve thought about this a little bit. I’ve had a couple of incidents happen to me in my career. And one that I really remember very vividly. Yeah. About, about the idea of wanting to create software, but the business not wanting that software is actually at one of my, one of my biggest enterprise jobs that I ever had.

[00:04:38] One of the largest companies I worked for, they, they, their portal infrastructure was running on classic ASP. And I’m like, no one wants to work on classic ASP. I mean, why would, why, why are we still on this? Microsoft’s been threatening to end support for this and, and why are we, why are we actually doing this?

[00:05:04] Why don’t we cut a push this portal infrastructure into the 21st century? You know, cause classic ASP, I seem to remember, I might be a little wrong. I seem to remember that came around in, in like maybe the late nineties as you know, so like 96 or something like that, you know, something like that. And cause I mean, asp.net was.

[00:05:31] 2001, 2002 timeframe, somewhere around there. So, you know, let’s bring it into this century. I kind of was my, was my thought and I had meetings with, with other developers and people higher up try to pitch this and they’re all like, but this other thing works and I’m like, yeah, but it sucks. It’s terrible to work on.

[00:05:58] Like I, you know, and they’re like, well, you just need to learn how it works. I’m like, okay. But that’s so there’s, there’s this balancing act. And this is something that I really had to deal with.

[00:06:14] Yeah. Something I don’t really think I’ve talked a lot about on the show, but my father was a software developer and part of his exit from the field was that he kind of went into obsolescence a little bit. And so there’s a lot, there was a lot of, if I saw things going in a certain direction and I could not get, you know, I needed to get experience with it in a company, because I learned that that was how you convinced other people that you had experienced was that you actually used it in your job.

[00:06:43] And, um, You know, that was kind of maybe my own limited, a limited perspective at the time. There’s other ways to do that. But I mean the best way to convince someone that you have experienced to say, I use this, or I spearheaded even implementing this thing. And, um, and so that was kind of, maybe my motivator was that I didn’t want to put on my resume that I had classic ASP experience.

[00:07:06] I wanted to put on my resume that, that. I brought this company out of using classic ASP into using all.net in their portal infrastructure. And I spearheaded and led that, that, um, that project. And so there was a little bit of self serving, uh, self-serving motivation in that, but. The thing is, is that what I didn’t think about in the reason why I lost that battle was that it didn’t actually help the business at all.

[00:07:38] Like there were a bunch of developers there. People, they, the company I worked for had no problem getting new developers to come in the door. It wasn’t like they were fighting to get people to come in. If you got with that company, uh, it was pretty good to have it on your resume. And, and so having classic ASP on there was just an annoyance for me, but it didn’t hurt the business.

[00:08:03] In fact, In my maturity being as far down the road as I am from that, that was probably about, Oh, I’m trying to think about the timeframe here. It’s 2020 and that timeframe would have been actually that timeframe would have been around the 2010, 2011 timeframe that I was having this debate. And so there’s been a lot of years.

[00:08:26] I’ve had to sit and think about that. I’ve gotten to sit and think about this. And when I look back on it, the right decision. Was probably just to stay with the technology that we had because it wasn’t going anywhere. I mean, they had just released a new version. I think what we were having this conversation, a new version of the operating system had just been released and they put the DLL in there to support ASP classic ASP.

[00:08:52] And that meant that it had at least 10 more years of life to it. Like if it was, if it was part of the operating system, it was going to be supported for at least 10 more years. So purely the, the conversation was where I was thinking about my personal, um, my personal status as someone who writes code, I was not thinking about the business and the business kindly came in and said, yo, wait a minute.

[00:09:16] This is. I had some developers on board with me that thought it was a good idea to get us off of classic ASP. But when it all came down to it, the business itself, the people who had been around longer had said, no, it really isn’t a good idea to do this. And I could not get, I couldn’t get past a certain level of support and it never went anywhere.

[00:09:36] But like I said before, the reason why I was talking about this is that I was trying to push something that clearly didn’t help anyone. I was just trying to push it for the sake of getting us away from what I considered an old, outdated technology that we needed to get away from. And that was, that was probably not the best thing that I ever did.

[00:09:59] And I look back on that and I kind of, I wish that I had been a little bit more mature when I was 10 years younger than I am now. But you learn things as you get older and you learn how to do, you know, you learn that there are reasons why things are the way that they are. Mmm. It’s not the only time I’ve ever seen something like, like what I’m trying to talk about, come up.

[00:10:18] But the, the main, that that’s my main experience. I tried to push something and it just wasn’t the business didn’t agree with me that it was needed.

[00:10:30] I think that’s an interesting, interesting proposition because there’s something to be said for being on the next wave of technology. Um, at the right time, but were you, was the portal something that was going to live for, like, you know, you could really unpack this right. From a business perspective, how long was the portal going to live for?

[00:10:52] Was it like a security concern? Um, You know, I know ASP had, it’s had its problems with security. Um, at least in its, when it was first, that was like the wild West. Um, I heard from someone. Yeah. So, you know, you could. So there’s, there’s definitely concerns. You probably could have brought up, but you’re saying, you’re saying you didn’t even approach it that way, um, from like a technical debt aspect or anything like that, you were just saying, I don’t want to work with this old technology, so you weren’t able to get buy in from the business.

[00:11:26] And that’s not how I sold it though. I did try to actually sell it as, Hey, it’s a data technology. Microsoft could say they’re going to drop support for it at any time. Of course the argument was, well, it just got packed into the last operating system. We have at least 10 years, you know, that, that was the first thing that came back from that.

[00:11:43] And the other part of it too, was that it doesn’t really support. Um, You know, it doesn’t really have good, supported it for good, for good programming techniques in PA you know, patterns and how we do things and stuff like that. It’s a, at that point and, you know, I tried to make all those points, but my motivations, that was the problem I wasn’t thinking about.

[00:12:06] I wasn’t actually thinking about how to save the company money or, you know, is this going to actually save them money? And the way that a company thinks about things is if we, and this is what this is the most, this may be the most important thing. When a company says, let’s go do a project, they’re assigning a budget.

[00:12:25] You cost money every day, you work on something they’re assigning that money that they’re spending on you to this one project and not another project. And so there’s an investment from the company that you are working for. That they’re hoping that when they have you work on this project, that there will be some sort of return.

[00:12:46] Now, if that’s a more stable system, if there’s problems with the system and it goes down a lot and they’re like, Hey Tyler, the system’s crashing a lot. Go fix it. And you know, they were having like, like a hundred crashes a day and Tyler gets in there and he’s a superstar and fixes it. And there’s like maybe one or two crashes a day.

[00:13:06] And. You know, or none even better, right. Let’s just say, it’s the perfect, like Tyler’s a rockstar and he fixes everything and there’s no crashes at all. And that means that there’s no slowdowns and the company can produce, um, you know, the company they’ll can process orders for, you know, a thousand more widgets a day, because then they, they could before, because there’s no friction anymore.

[00:13:30] That is. That’s a way of saying that, that, that endeavor brought us something. There was a good reason. Tyler took off from his other project that he was working on to stop what he was doing to go fix this. And that’s the kind of thing that I, I really wish I learned earlier on, but I didn’t really even realize I just went to work everyday because I liked to code and I wanted to make things and people ask me to make things that I really never even thought about.

[00:13:57] Am I making something that is going to help the business or am I just on a fool’s errand and I’m just making stuff to make stuff. And I wish I had thought more about the business earlier in my career. That’s why we’re talking about this right now. Right? So I think actually, sorry, go ahead. I was gonna say that I had something come up recently that I saw on the internet that made me think about this concept, but Tyler, go ahead.

[00:14:26] So there’s a sheath if different things there. I think, I think one, one of the, one of the paths we can go down as the importance of understanding the domain, as well as eliciting good requirements from the users. Um, another one is, um, Something that I’ve struggled with is getting so myopic on the, the problems I have as a developer and focusing on.

[00:14:48] Okay. Like, Oh, I don’t like, like, for example, I, I really dislike when, um, something doesn’t build correctly, right. When there’s, when there’s, when you repeat the same mistakes over and over again, like I’m prone to do. I want to fix that with automation in some way. Right. So automating a builder or putting in good documentation and things like that.

[00:15:10] Those things can tend, um, you know, documentation is not typically a strong suit of most developers. Um, and I tend to lean more into documentation because my personality, I like for things to be consistent. I like for things to be understood and to look at old mistakes, not repeat them. Uh, so my question is, um, before we get into the, maybe the domain stuff or whatever, Sorry, do you want it to go off on too?

[00:15:33]Um, how, how can I, as the developer, um, kind of think at a high, higher level and not get so myopic on the day to day struggles of being a developer, but focusing more on my, on my. My company’s needs, because if you don’t, if you don’t focus on what your boss cares about or what their boss cares about, um, you might not last long at a company.

[00:16:01] And so how did you, how do you do that Douglas?

[00:16:08] So the question that you’re asking is, is how do we know what our boss really cares about? Is that, is that kind of the idea? Um, well assuming that your boss cares about. Right. Assuming that your boss is competent and cares about the business and cares about, um, making, making a profit. Right. Because if we don’t make a profit, we don’t have jobs anymore.

[00:16:29]Um, unless we’re, you know, in the government or something, right. It’s like where you don’t need it worried as much go there. You don’t want to go down, but I’m saying, um, Assuming that you’re, you’re a normal business and you need to make a profit, right? You’re not a nonprofit who’s funded by someone else.

[00:16:43] So your outcomes aren’t weighing on that. Um, and your, and your boss has to, uh, Your boss is worried about that. How can you, how can you pivot to where you are producing what your boss wants versus being so getting so into, into the day to day of your own job and trying to make your own job easier? Does that make sense at all?

[00:17:06] Cause I, I, I tend to do that. I’ll be like, okay, I want to focus, fix the stuff that I care about, and that might not be the same thing my boss cares about. And, um, And that can put you in a precarious situation if you’re not producing what your boss wants. Right. So most of the time, you know, and I I’ve.

[00:17:26] I’ve been in and out of development a little bit. This is an odd thing to think about, right. I, I went and taught for about eight months, a couple of years ago, and now I’ve been teaching now for about six months. So I’ve had a couple of breaks in development and I’ve had a different, I’ve had some different things come up where my concerns kind of transcend it development a little bit.

[00:17:47] That’s a, that’s probably a topic, an interesting topic for a show. It may even be where this topics coming from. Um, But how to know. Well, there’s a really good way to know, which is typically in most groups that I’ve worked in. Um, we, we have. You know, there’s some sort of planning going on. There’s some sort of project that you’re on.

[00:18:11] Now, let me say this. Those are good ways. Those are good signposts. If, if you are, if you’ve been pulled in a project, you know, most of the time, we’re not just sitting around doing nothing, either we’re sitting on a project or there’s a queue of bugs that we need to go fix. So if you’re doing some maintenance, some, you know that there’s always something that is going on.

[00:18:32] The questions are different depending on where you are. If you’re working on a project, then again, that is where some people have said that we think that if we can make our program, do X, Y, Z, that is going to be better for the business. Can we get a group of developers to go do this? So that’s important if you’re on a project, that’s probably the most important thing.

[00:18:57] The, uh, the other piece to this. Is that if now if you’re fixing bugs, if you’re a, you’re doing like a break fix kind of thing, or you’re the NC, this is where it gets a little, a little trickier. And this is kind of where I think the topic came up that, that alluded to this show in the first place. Is that if you do have something that comes up and you find, Oh, there’s this weird bug that occurs.

[00:19:21]Um, I think the example that I had seen in this big, a little too close to the, to the incident, I don’t want to call it out directly, but you know, if you happen to have a system that requires an image, uh, Mike, let’s say you have an eCommerce system. And somehow it’s an interesting state where unless that, unless the image of the product is available, orders are not processed.

[00:19:45] That sounds very strange to me. Right? I’ve I’ve worked with a lot of e-commerce usually you get an order, ed, you want to get that thing shipped and get it out the door. Cause someone has given you money. There’s a possibility that people take their money back. If you don’t get their product shipped, that’s the thing, right?

[00:20:01] This is the business case, right. You’re sitting here and it’s not just, what do I do about this error? Do I log the error or do you know, don’t think about just that, think about the whole ramification to the company that you’re working for, um, as to, as to whether or not, um, as to whether or not you are, um, A change that you see a bug that you see something that’s going on.

[00:20:26] Is there something else that this causes not like, Oh, I need to figure out how to log the error. It’s maybe I need to ask. I just noticed that the system is not going to send a product. If an image is missing. I would actually, at this point in my career, I would stop everything I was doing for the moment, because I was asked to go fix like this locking problem, but I would like, wait a minute.

[00:20:49]Um, why did we not ship something? If there’s no image? Why do we not process orders for something? If there’s no image, that would be my first question. And then, you know, maybe there’s a reason, so I don’t go, I wouldn’t go in there. Guns blazing. Like this is the stupidest thing I ever heard. Why are we doing this?

[00:21:07] This is not the way it should ever be. This is e-commerce. People are gonna think we’re crazy. Um, there may be a reason there may actually be a business reason, but then based on that business reason, if there is one and it has to stay that way then yeah. If you want your goal as a developer is to help the business keep moving as fast as possible, especially if you’re doing some kind of, um, you see some kind of bug or something going on or something weird going on.

[00:21:35]Um, the, the whole point of the business is to get the product. Out the door as fast as possible to the customer. And if something is causing friction to that, that’s the question, right? And this is, does come down to understanding the domain that you’re in. Right. But if something is causing a slow down in order fulfillment and you work for an eCommerce business, Then there needs to be a conversation about that.

[00:22:03] Not a long one, no guns blazing. Just I noticed this and why and all right, here’s a proposed solution to get the problem fixed the fastest. We’ll send an email to the person, responsible for the product to get an image in there and try to come up with some way that as soon as an image is placed, that we reprocessed the, we try to kick the order process off.

[00:22:22] As soon as it image, you know, there’s, there’s this, there’s these questions and there’s these proposed solutions you can come up with to fix problems. And the, the kind of outcome that, that I saw from this was, was, you know, I just need to figure out how to log the problem. And I’m doing a favor. If I send an email, I’m like my thought was I’m I’m.

[00:22:48] I get it. I was there. I understand that, that line of thinking. I remember a time where I may have thought that way, but being in the different sides of the business that I’ve Ben Allen has given me some insight into what my code is actually supposed to do. And if I see something wrong, it may not be, it may not be weird intentionally if it just a conversation we’re had with people about, about the process and why this is occurring.

[00:23:15] It may have just been some weird mistaken code made years ago. That was not really noticed until you went through and decided to look at, um, to look at whether or not, you know, to look at whether or not you should log this air or not. No one may have known about it, which actually brings up other arguments too.

[00:23:32] But that’s, that’s kind of the thing is that there’s, there’s the two sides, right? One is one is this holistic, um, Is is the project I’m trying to get into going to help the business. And the other side of it is I’m actually seeing this really weird behavior in the system. Should I log the air? Uh, probably probably you should, should go and have a discussion about it with, with your manager and team and figure out if that’s really what the system should be doing.

[00:24:01] You may have just found a bug that no one that no one really understood that was occurring until you found it. Yeah, I’ve, I’ve struggled this with this one, myself. I’ve even brought up things to supervisors before, um, or whoever’s over me and be like, Hey, do we need to worry about this? Cause I I’m, I’m constantly looking for, you know, as developer, uh, looking for different things that show up, but I’ve also been in a camp of ignoring, uh, issues that I see because I see so many of them, right.

[00:24:31] If you’re in a certain type of code base and you see so many different types of errors, Um, now that’s where I think it gets into a few different things is company culture, as well as, um, just not knowing, uh, I guess company culture would be the biggest thing that would come down to is, is, is your company, is your company one that wants to know about all the issues that occur?

[00:24:53] Are they in? Are they. Open to discussing that. And do they have proper channels for communicating the issues that you find? Right. So, um, because it’s hard, it’s a hard thing to prioritize. Cause I, um, like I mentioned before, sometimes I, I don’t have the best, uh, prioritization meter because I get so. Myopic on the specific issue where it might not be that big of a problem in the grand scheme of what you’re trying to create is, you know, making a, you know, what’s the saying, making a Nat, uh, making a mountain out of molehill, right?

[00:25:27] So if like, if your whole company is going to, you know, Your whole company is going to go down. If you don’t fix this one bug, but you’re focused over here on this, the small technical debt. Well, you you’ve got a miss prioritization issue that could cost you your job, right. Just because of the nature, like it could cost everyone their jobs, right?

[00:25:47] Like it’s a very extreme example, but I think that’s definitely a culture thing. And I’m a communications thing which comes back to culture. Well, technical debt is a different story than what I’m talking about. So the one thing that I, that I said that, that we were, that we were talking about is actually someone getting their product that they ordered is affected.

[00:26:10] The business process is affected by a bug. Um, technical debt has to do with. You know, if you happen to have and like, and, and let’s be really clear here what we say, technical debt. It’s like, well, if we did it this way in this pattern with this architecture, then it would be so much easier for us to maintain.

[00:26:31] And we have an in our industry, we do have accepted patterns and practices that we, that we typically try to use. But sometimes we come into some really strange code bases where people did crazy stuff and, and, you know, people decided to do the crazy stuff. And when they decided to do crazy stuff, to get something out the door fast, That’s a debt that’s built up.

[00:26:50] That’s going to have to be handled later saying that I’m getting, getting zeroed in and, and do you and I, um, I know that we were probably pretty similar at the, at the points in our career that, you know, like when I was mid level, um, or even some somewhat senior in my career, I thought that there was the one true way.

[00:27:11] And if everything had to be done the one true way and you know, I don’t care if it takes. Takes an extra a hundred years to get it done. Right. Let’s do it right. And the answer, the dogmatic programmer, right? The talk automatic programmer. Yeah. It’s so, so the thing is, is that that with maturity comes, you know, again, our code, the number one reason we get paid to write code is because some people think that if we write this code money will be made.

[00:27:44] That’s the number one reason why. And so the biggest thing that I want to, to impart here is that our number one priority should our prioritization should always be, if anything is stopping money from flowing, we should fix money flowing problems. If we now have time and there’s some technical debt to go solve.

[00:28:06] Let’s see if we can get people to agree to that because we did such a bang up job on the money flow problems, uh, that we can come back and work on the technical debt. Now, I will tell you something from having a lot of years of experience that time rarely ever comes. So the flip side of this is that if you know the processes that you should use, when writing the software, initially you should use good practices.

[00:28:33] The better practices of the day when you are writing software. Now I agree with you and that’s, that’s one of the things this might come back to bite me in the bud, but like, that’s one of the reasons why I don’t like startups as much as, because startups are so focused, rightly so, so focused on pivoting.

[00:28:54] So focused on getting code out the door as quickly as possible, um, that they don’t necessarily focus on. Um, the quality of the code and there is a, um, there’s a startup. I know that uses the extreme programming. So they’re doing TDD, paired programming, uh, practices, you know, test driven development, uh, which is TDD what’s TDD stands for, which is kind of a way to, um, it’s a loaded subject.

[00:29:20] We can go into it at another time, but, um, It seems like they don’t have to be in mutually exclusive necessarily, but most companies I don’t think. Yeah. Um, I think it’s very hard to, it’s very hard to, um, get buy in from most, uh, managers to use good practices at a, at a startup. I think it’d be really hard to, or the best practices, right.

[00:29:48] And bad, best practices being that’s a loaded term as well, but you want to call it her better. Yeah. Um, what are, what are some of the better practices that you can follow? And we know that, you know, automated testing can help, help you with, uh, discovering, uh, what’s wrong with your code, potentially theirs and theirs.

[00:30:09] There’s no silver bullets out there. And that’s something I’m realizing more and more, but you can have a lot, but most of, most of the arguments that I’ve seen against stuff like TDD are straw man arguments where they’re like, well, yeah, if you write bad code, right. If you write bad tests, you’re going to have bad tests.

[00:30:27] That doesn’t mean you shouldn’t. It shouldn’t do test driven development. You’re just putting, building a straw, a straw man argument that you can’t write good tests. And so maybe if your strength isn’t in writing tests, then don’t go to a company that focuses on those things. But I think that, um, I think that it’s, it’s definitely, uh, it’s definitely something to consider in your career is what, what type of culture do you want to be at?

[00:30:50] And you have to understand that the type of business, um, depending on the type of business that you work at will depend on the processes that you use. Right. Cause there, because there’s that Conway’s law where, you know, kind of the, the, have you heard of that one before? Yeah. I mean, I’ve, I’ve read about it.

[00:31:09] So if you want to go through it, no, it’s just, uh, Conway’s lie, I think is, let me, let me pull it up really quick. So I don’t, um, Conway’s law is an adage that stating that organizations design systems that mirror their own communication structure. Mmm. I don’t know if that goes down to the actual architecture itself, but I think it definitely, um, uh, Okay.

[00:31:30]Um, it’s, it’s an interesting premise, right? That your culture, you know, what you care about, do you care about really clean code? Well, that’s going to show within the culture of the company that that’s what the developers there think about. Whereas if you’re more of a startup culture, you’re going to worry about getting code out the door, you know, and you think more of the, uh, the Tenex developer thing is like, Hey, I’m going to get all the code.

[00:31:50] I can out the door. Right? No matter. Um, what, what cost it might be? Not that there’s, that’s a whole load of thing right there, but, um, uh, go check out to next developer. That’s a whole other, that’s a whole nother show. We could do a whole show on, on the concept of the, the, uh, let me put it out there. The myth of the Tenex developer.

[00:32:13] Did I just let my, let my position out. Maybe I did. Maybe I didn’t, you’ll have to tune into that show when we finally do it, I gotta go drop in the spreadsheet. Um, but I don’t, well, that’s, that’s real let’s will it back in, I don’t know, uh, what thread we were just on. Cause I kinda kind of went off into a dead end there where it just could, the thread kind of terminated for me.

[00:32:35]Um, but I’d like to talk about domain at some point. Sure. And I want to, I want to really emphasize the, the main thing about the other story that I heard. They’re still baby thinks. I don’t understand when you read things on the internet. So this is what I want to really emphasize. It sounded really strange to me because someone posted something on the internet and, and the conversation got a little, a little strange, but the thing is, is that.

[00:33:00] Again, there may be reasons, and I may not even understand the situation. So I want everyone to be really careful about that. Um, I don’t want to take too far from, from the topic, but I did just talk about something that, that maybe I have no clue about what’s really going on with that. But I’m just saying, from what I heard on the outside, It really triggered this, this discussion in my first of all in my head.

[00:33:23] And then I really, I sent you a text message really quick after this happened. I’m like idea for show you both. This, this really happened very quickly, which is that, that, uh, we need to talk about the fact that, that when we do work as a developer, that the reason why we’re being paid to work as it, and that’s the, this is the number one thing.

[00:33:43] This is the number one consideration that you need to make. As, as a software developer is that someone needed to get some software written to make it so money can flow from point a to point B somehow. And that’s, if you’re writing a product, that’s providing some kind of service. Well, that, that means that money is flowing to your company because of that service you’re helping to provide or quite literally.

[00:34:11] You’re writing e-commerce code that is taking money from people and processing orders and sending them product based on those orders. So somebody accompany is decided that by firing you and paying you very well to write software that you are going to. Make them more money than they’re paying you because they’re paying you to write software.

[00:34:34] That’s the number one consideration as a software developer that you need to make is that they’re paying you because they’re thinking you’re going to make more money off the fact that they’re paying you to write software. It’s not a charity, right? So that means that you have a responsibility to try to do your best, to understand, um, To try to help the business not hurt itself as well.

[00:34:59] Right. So to try to think through the use cases and go, I don’t think, you know, based on what I know about the domain, right. And the domain being, let’s kind of define what domain is, domain being. The, um, the, the business and its terminology and the complexities of that business. So for, for example, I work at an insurance company that could be one domain, um, and that can get, that can be broken down into sub, uh, different types of insurance and things like that.

[00:35:25]Um, uh, what’s some other domains e-commerce is another one. What’s some that you have with that domain. We’ve touched on that. Um, I’ve worked in manufacturing. So that’s a domain that I actually worked on software that, that, well, I worked for a company and I actually worked on different pieces of this software, but they actually had a computer aided engineering product that created files that were, uh, that were then fed into like all this code was internal that were then fed into, uh, manufacturing, uh, systems.

[00:35:57] And then actually manufacturers picked up that those. Those Rose out of the database, after those files were dropped in and made parts, like actually made the parts and shipped them out. So I worked in manufacturing and actually got to work in some of the, the, the nitty gritty. I got to write code that that was printing out, uh, putting out plans and all sorts of stuff.

[00:36:21] It’s really cool. It’s actually, it’s actually computer. It was software engineering to help engineers. It was great, awesome structural engineering stuff. And then, um, I worked in logistics for a few years, so that’s a whole different domain, right? How do we get products from point a to point B? So I learned a lot about logistics and, um, then, then also I worked in retail fuel, so not just retail, but actually a sub domain of retail, which was retail fuel.

[00:36:50] I worked for a gas station. It’s funny when I say that, but I actually worked for their home office then, uh, you’re selling, you’re selling the cigarettes and the, uh, Yeah, all the convenience feeds, you know, the interesting part was that I didn’t work on software that sold cigarettes. I know that person who, that guy made a lot of money for the company, because they would see a change in the contracts for the rebates for the cigarettes.

[00:37:18] And he would be the one that go in and make the changes in the software. And he’s like, I just paid the company another million dollars by making this change, you know, he’s, you know, he was really proud of that, but then I’m like, well, how much are they paying you then? Wasn’t it. So that was that’s a, that was a, that’s another interesting conversation right there.

[00:37:38] The, um, I did get to write the software. I actually wrote a payment system. I wrote the inner workings of a payment system while I was at this company and got to help with the code that that would lock down. You know, you could actually give your kid a sub account on this payment method and. Not let them buy cigarettes.

[00:38:01] You can limit what they could buy. Yeah. So that kind of made me feel a little bit better, even though, even though I worked for, like, I think they were like the number two retailer of cigarettes in the country, um, I actually got to work on software that kind of helped limit that a little bit. Right. And so something we didn’t yeah, lots of domains.

[00:38:20] And we’re talking about business, like a better definition is this, these are what business domains are. Um, I think is kind of the more specific term, uh, cause domain is like a loaded term inside of, uh, uh, you know, with networking and, uh, IP and stuff like that. Um, Oh yeah. So business domains, um, Uh, there’s a lot of complexity going down inside of there.

[00:38:40] And it’s, I think this comes down to company culture as well as how much is the company investing in you at? Like how much do they want to give to you as a, um, developer? Right. So in large enterprises, they might insulate you a lot from. All the different, the entire business domain, right? You’re not going to see the, you might not see the overall overarching picture for your company.

[00:39:06]Um, and you’ve worked at large enterprises before, um, What have you seen? What have you seen before? What’s the difference between that and a, uh, a mid to smaller company where, you know, mid-level being, uh, or, uh, uh, small to mid sized business, you know, midsize being, you know, 50 developers or 20 to 50 and small being like one to 20.

[00:39:24] What have you seen the difference between, um, between those, uh, those different atmospheres and how much you have to understand about the business domains? So the interesting thing about this is that I actually worked one of the companies when I worked in logistics, we had seven developers. Right. But there were like, there was over a hundred employees.

[00:39:47] So we, there were very few developers supporting this product that made the company a lot of money. As far as, uh, from the website of things. There was another development group inside there that headed up the ASMR four hundreds and stuff like that. So there was another, a little bit of other development going on, but the front end of it.

[00:40:06] Which is funny, I say front end because I did all the ends, you know, I just didn’t do the part. I did all the ends. That’s, that’s a quote, that’s the quote of the day on this one that I did quote of the day did all the kids, that’s what they do by full stack. I just didn’t know it at the time or that they were, they were in the first place.

[00:40:25]Um, that’s, that’s another topic for another day, but no, the thing is, is that, um, That company was considered a mid sized company, but we had a very small group of developers that handled a lot. I think that that’s actually a little bit more common than you think it is. So that was the first thing. The second thing is.

[00:40:50] And well, let me, let me think about that for a minute. So in manufacturing, we had lots of employees in the manufacturing side of things, but as far as developers were concerned under 10, under 10 developers. So the size of the business does not correlate the size of the development group. That’s an, that’s a interesting thing I had not thought of until you just brought that out.

[00:41:12] Like, what was it like working for a midsize company? Now I have worked for a major bank before. A large bank, probably one of the largest banks in country, maybe. Yeah, I think so. And I’m up there at least in the fortune 50, right? So that one was you’re right, totally isolated. You didn’t sit in, you had no chance to sit with executives at all.

[00:41:40] You were within your own group. Um, There really, wasn’t a way for you to affect everything going on in a company like that, unless you were really like, Oh, one of those projects right there, there are, there is a such thing as, as a project that everyone will use, like maybe you’re working on the, the website for the bank.

[00:42:01] Everyone who will touch this. And if something goes wrong, the CEO will probably hear about it. So depending on how badly it goes wrong, but in that situation on right in that situation, you have. You have lots of different teams. You have lots of, I mean, you had, we had an architecture group, right. That all the decisions about architecture would go through and it had to be vetted and versions had to be vetted and audited for security.

[00:42:33] And it was, everything moves so slowly and in that realm, but rightly so, like you want to hear, like, I’m telling a story you’d want to hear at the bank. It’s really hard to move to a new version of anything. Because everything has to go through security audit architecture has to, the architecture group has to see how to assemble it.

[00:42:53] And then it gets passed down to the engineering group to go put it together. And it’s a, it’s a way different, it’s a way different process than what I was used to ever. And I didn’t stay there that long. And then, and then, and then we had, and then I’ve worked for ’em. You know, I’ve worked for companies that would be considered large companies.

[00:43:16] So I’ve worked at the, you know, the 170, like the, um, what is it that I’m trying to say? The, the, uh, uh, A fortune, a fortune one 70 company, which was a little bit different than a fortune 30 company or 50. And at that level, we had lots of people in technology, lots of departments, but really one development group that did a lot of the work.

[00:43:38] And a lot of the like, like web development work, all web development with one group. And I was in that group and. That one was a little bit different. They wanted to be sure everyone knew what was going on. So we’d have company-wide meetings where at the home office, this the. CEO would talk or the vice president would talk about, about what’s going on, what the vision is, and just kind of give you an idea of what was going to happen.

[00:44:07] So I see it’s way different. And even at that company where, where I was like one of seven developers, I never sat in an executive meeting. I never sat with people above a certain level and heard what the vision for the company was. But when I worked at that huge company, You know, when I worked at not the biggest, the biggest, but when I worked at the, you know, when I worked for the retail fuel company, um, yeah, they, it was a very close knit home office and they wanted everyone to know what the vision was.

[00:44:34] So we could all walk in lock step together. So it just you’re right. Culture is a hundred percent even, no matter what size the company is. I guess the moral of the story here is that you can, um, you can keep your employees up to date with what your ideas are. And I would even say that that even if you didn’t have that vision from, from your executives, You still kind of know, you’ll learn the domain itself.

[00:45:03] If you’re city can retail fuel and you’re sitting in the, in the fuel department and your job is to write code that that records fuel being put into pipelines. Cause that’s how we move fuel around. In the U S as they go into these big pipes and you take the fuel out in the location that it’s supposed to go into.

[00:45:21] So you start off at this one location, you push a bunch of fuel in, and then your truck at the receiving end can pull up to the terminal and pull that much fuel off. And it’s kind of one day, we can have a talk about that, how that works, but I don’t want to do all of that here, but if you’re writing code that maintains that you see something weird about Paul, if, if this keeps going like this, something weird can happen, right?

[00:45:43] And maybe we don’t record something that needs to be recorded or something more gets recorded that can cause us compliance issues. Maybe it’s time to start, you know, you start going up, but see that takes learning about the domain that you’re in. Not necessarily about the vision of the company, but what are the rules about what I’m writing code for?

[00:46:02] What, what is it? What am I actually doing? I’m not just writing code to write code, which is what I did for a long time. And I was actually, look, I never had trouble keeping a job. Every time I left a job, it was because I left the job and I had another one to go to. And people, usually I had one manager scream at me when I turned in my resignation.

[00:46:23] I got screamed at for returning, for turning my resignation in. So it’s. Um, like I’m guessing of way. And while screamed at, as in like, like, you know, what have you done to us Douglas? And then, and then like someone else walked in and talked to him and said, Hey, you know, you’re gonna, you know, we could probably try to keep this guy.

[00:46:40] If you didn’t scream at him. It was hilarious. That was the guy above my manager that was yelling at me. And then my manager walks in there and has a conversation that he brings me back and says, is there any way that we can convince you to stay. That’s what I’m saying is that, is that even with the understanding that I was writing code to try to keep money flowing easily and with less friction, I still was worried about, about writing high enough quality code, that when I did try to leave a place that people usually argued with me about it, it was an argument they wanted me not to leave and to stay.

[00:47:17] And so, um, But I will say that the one thing that I think that would have caused me a lot less losing a lot less sleep or a lot less brain cycles over things was that if I just remembered that I was writing code to try to keep things, keep the business going and not so much about, well, they’re not letting me use MVC.

[00:47:37] Cause there was a time before asp.net MVC. Uh, and there were people that were against that pattern when it first came out and it’s, it’s crazy, but there’s, there’s people that were against every new pattern that came out. But if it was, if it was more about what am I doing to help the business, and then I wrote resumes, this is the other thing to writing the resume to.

[00:47:59] How did you help the business? Well, these are, this is the code I wrote, and this is how it helped the business. Do you know what that would do to a manager that saw that resume? Like this guy is writing code and thinking about helping the business by writing the code, like he’s actually stating how the code actually helped the business.

[00:48:17] That’s going to give you a leg up even before you walk in the door. And they talked to you about how you code that may even change your technical interview a little bit. I think that could, I think it’s interesting. Everything that you’ve, you’ve touched on. And, um, I agree with you in large terms, but I also, I also think that.

[00:48:40] We’ve talked about this before in that in software development, everything comes down to like, it depends, right? I think that this, this question what’s your most important responsibility comes down to it depends. And I think that you can decide it depending on. What company you pick and the culture that predominates of that company or within the team that you’re going to join.

[00:49:02] So what do you think about asking, you know, asking potential employers? You know, what’s the, what’s, what’s my main responsibility. Right. Not my actual technical responsibilities, but what are, what’s my overarching responsibility? Like, what are you, what are you on me to say, see day in and day out. When I come at this job, how do you think approaching, um, finding a job in that way would, would set you up, um, differently versus not asking that question.

[00:49:31] How I’m trying to put myself in the position of advantage, or that’s just been asked that question. What do you expect of me every day? And the thing is that question is so open though, that I may not understand the true reason why you’re asking me that question. So yeah. You’d have to give him some examples.

[00:49:53] So you go, okay. Um, Because this all comes down. So the culture things have been big for me because I’ve realized like being in the right culture can help you succeed in your strengths. Right. So you’re your biggest strength? So some developer’s biggest rate might be writing code. Some might be communicating, right.

[00:50:10] And being the mesh between between teams or. Eliciting requirements, right? If you, if there’s no B, if there’s no BA, if there’s no business analyst and you are really good at getting requirements from end users and turning that into code, you might not need to be the desk developer, but you might have better communication skills.

[00:50:28] So I think. I don’t have the exact wording, but you could give different examples and go, okay. Um, you know, what, what are you hiring me for, for my skillset? Is it just like, is it just coding or are you wanting some, like, here’s my strengths. Right. Do you see these strengths as being valuable to you as a, as a organization?

[00:50:48] And you’d have to pitch that in the right way so that it’s not used against you, right? Or just, um, or. Not used as, um, uh, you know, that they’re just going to hire you without actually using your strengths. Cause I’m a big proponent of using your strengths at the companies you work at.

[00:51:07] So I still think that the, the question in an interview might be, might be taken. You know what, it’s a fair question. So the actual question itself, and I’ve actually even seen just coming into mind right now, I’ve seen it listed as one of those questions that you should ask. What do you see my day to day responsibilities?

[00:51:28] Looking like, you know, what is it that you would have if you were to hire me? What is it that you would have be doing every day now? And it depends. And I hate saying it depends. Cause it seems to be such a cliche thing to say, but here’s what it depends on. If you’re a junior. At the point where you’re a junior, it may, your job responsibilities really may be to work with a senior level developer to accomplish tasks.

[00:51:55] Senior level developer gives you, it may not even be to have that much of a, um, That much of a say in, in certain things like, like, well, why would you do this or that? Cause you probably don’t know why would you do this or that yet you’re a junior developer. And, and so in that, that position, it really would be like talk to your lead and let’s, let’s get some stuff done and you may not know to question things.

[00:52:23] As you move up through your career, though, what you hope to hear is something along the lines of, we were looking for someone who is going to be a member of this team that will help, you know, that will not only write highly maintainable code, that that accomplishes the goal of, of the project. But also we’ll be on the lookout for things that we can do to do things better.

[00:52:51] And if you hear something like that, then, then you know that you’re working for a company that is looking for feedback from the people that work for them. If someone actually calls that out, then you know, now implicitly, I wouldn’t have known, I wouldn’t have even thought about trying to deliver that message.

[00:53:10] But implicitly, I expect that if I were to hire a developer, I need them looking at whatever they’re looking at and come at me with, I found this really weird thing. Can you kind of go like either one, tell me what this is. Like I may have just found it. Maybe I may have just found a bug, something kind of doesn’t intuitively work right here and let’s have a discussion about this and then you kind of look at it and go, Oh, right.

[00:53:34] You’re you’re totally right. That. I, we didn’t even know that it was doing that. Thank you so much for finding that code. And, and let’s, let’s put that in the tracking system and let’s get it prioritized and we’ll put it on the list to get fixed or to here’s the business case for why this happens. Let’s figure out a way to make it to where that problem gets fixed faster.

[00:53:57] You know, the problem that, that causes that weirdness to occur, you know, let’s, let’s figure that out and. No, I would expect that, like, if I were hiring a mid level to senior level developer, I would want someone that’s going to come in and tell me if they see something that’s a little off from their intuition, you know, intuitively this does not work the way I would expect.

[00:54:20] Like you’re going to work for an eCommerce site in orders. Don’t get processed. If this thing that happens doesn’t have that doesn’t even have to do with whether a product is available in our, in our warehouse or not is stopping orders from being. Process because some digital asset doesn’t exist. Then talk to me, let me know that that’s a problem and let’s, or let me know that potentially could be a problem.

[00:54:43] And that shows me that you’re looking at stuff, right. I w as a, as a person that potentially could hire developers, I would love to see that I would, I would love to see that. I think, I think it just came to me as to how to pose us. And this might be kind of, um, uh, we did that interview with Eric recently and he, he had some really good golden gyms in there of, of how, how to approach interviews and different things like that.

[00:55:11] But. I’m wondering if you, you know, how you know, how employers love to give you the, um, and maybe you’ve done this before, but they’d love to give you the, the hypotheticals of like, imagine you have a difficult, you know, you have this scenario of a, of a, uh, difficult, um, coworker that you’re working with or whatever scenario, how do you respond to it?

[00:55:33] I think if you did the same thing to them, But instead gave them how you like to work. And you say, look, if you’ve ever worked with someone that, you know, constantly ask questions and constantly questions, the status quo, like that’s more of like me, right? So like I’m constantly questioning like, okay, why are we doing what we’re doing?

[00:55:54]Um, how do you respond to that? Cause if you can get, if you, if they become hostile to that way of thinking, right. If you have more of a, you know, Uh, sit down and shut up attitude. You’re going to know once you’re going to know that you don’t want to work at that location because that doesn’t mesh with your skillset.

[00:56:10] Okay. And so I think taking your, taking your strengths and posing them in the right way, it’s going to allow you to actually use your skills in conjunction with how your boss wants you to perform the job.

[00:56:37] I was gonna say, I like that a lot. So the main thing is that, um, what I want to say is, As far as listing your strengths, this is something that what’s your super power, right? I’ve been asked that a couple of different times. And if you come in and say, my super power is that if I see something that is, that doesn’t look right to me, I will say something about it.

[00:57:04] Right. That’s that’s a superpower. I question I’ll question. What is going on? Not from a critical lie, but from a curiosity and, and from a, you know, maybe this is a potential issue, but not from a, like, this is the worst thing I’ve ever seen, you know, kind of perspective. That’s going to show a lot. If, if you kind of say that or let me give you a scenario, like, I kinda liked that where you turn the scenario, we, in our mock interviews that we have for our students, we have the question about, um, if, uh, what was the last conflict that you, you know, the last major conflict you had at work and how did you, how did you wind up handling it?

[00:57:41] You know, that’s a, that’s, that’s one of those questions, right? I, uh, that everyone, you know, it’s usually like that falls into, what’s your greatest strength, what’s your greatest weakness. And, you know, then you just go my greatest strike this, that I’ll I’ll work until my fingers. I’ll I’ll type until my fingers turn to bone.

[00:57:58] And then what’s your weakness. I type until my fingers turned to bone, that’s my weakness. You know, that’s, that’s how you handle that question. You know, I’ll, I’ll keep coding until I die. That’s that’s a weakness. In a string, but exactly I’ve almost coded myself to death before. It didn’t quite, quite good all the way there, but I’ll tell you, when you go for like weeks of slew with, with about two hours of sleep a night, I know what that feels like 18 hours a day.

[00:58:29] Luckily I was paid hourly.

[00:58:34] You have the right incentives there. I I produced, yeah. I produced the work like they’re like, can you have this ready for rest by the morning? And I’m like, it’ll be ready. And then someone actually actually, uh, kept, kept, uh, woke, be up. Like I went to bed for two hours and they woke me up and I started coding again while they slept.

[00:58:50] And then, and then, yeah, it was I dude, I don’t, I’ll never do that again, but it was an extreme to have a, uh, you know, uh, uh, um, battlefield stories, episode, you know, the. Of all this stuff you’ve been through. So I think so I would work myself. So that’s the thing. Let me, let me get back and wrap and kind of put a pen in this.

[00:59:11] Yeah, the question is that. You know, what would you the, the interview, right? How would you be if, if that would be an acceptable thing for you to do? I think that it also depends on the level that you’re at. If you were a senior level developer, I expect, I expect senior level developers to. To have that critical eye to always be thinking, is this code working the best way possible?

[00:59:44] Are there weird things happening when they come across them? And will they get that message to the right people? If there are the strange things going on, um, as a mid level, I would love to see that like, just, just as someone who, who, um, Just just as me as someone who might, you know, at some point, be in a position to start hiring again.

[01:00:05] And, uh, you know, looking at that, uh, Mid-levels I would, I would love for them to be trying to do that. Now. It never criticize someone to come. They came to me with, this is kind of strange. What’s up with this. Like, tell me about it. What’s the story behind this. That’s really the way that I try to handle things.

[01:00:21]Um, what I don’t want is someone to come in with guns, blazing going, this is the worst crap I’ve ever seen. What’s wrong with you all, you know, and they’re like a junior. Right. It would be a real, Hey, I’ve actually seen this. Like I had one, I had one junior developer that I dealt with. Everything needed to be rewritten because it was the garbage and I’m like, no.

[01:00:45] Or the not written here, problem where if you don’t use other libraries, cause you have to write them yourself. You don’t well, it wasn’t a not written here. Problem. I think it really was that he was so junior that, that he couldn’t read code well enough to understand, like he was having a hard time understanding what the code was doing.

[01:01:04] It was not written in the exact way that he needed to see the code. Therefore, everything was just like, whatever you wanted to do. If you need to touch the code, it needed to be completely rewritten. That was, that was his initial response to everything. Cause it was so bad, it needed to be rewritten and I’m like, that’s not necessarily true.

[01:01:23] So there’s, there’s definitely a side to this. There’s some nuance to it. This kind of goes into one of my, I don’t like the name of this, which is soft skills, which is you see something you think is wrong, but you need to collect data on it. And the only way to collect data on it is to nicely talk to people about it and see what they have to say, get reconnaissance on why this weird thing is there.

[01:01:48] And then once you can build a case up and put it together. Then you come out and go, Hey, I think I found something that’s wrong. Can we, can we talk about it as a team? And, um, and I don’t know if we’ve, I don’t know if that’s buttoned it up or not, but I mean, as far as I think the question was, was going to be one of those nights, it’s late.

[01:02:09]Uh, we, we went on a different, a few different streams. Like it was like, you know, the. The way that I word it was like, what’s your most important responsibility? Or, you know, we’ve, we’ve said what’s, what’s one of the number one reason why you get paid as a developer or, you know, that the business is your business as a software developer.

[01:02:27] Right. There’s a few different threads that are very similar. Yeah. And I mean, I think, I, I think I kind of nailed down. The thing that you were talking about, which is there, which is that maybe how do you find out if the culture is going to support that or not? I mean, I’ve said it from my side. I would want to hear someone say that they do that kind of thing, but I also want to hear someone know or be humble enough to know that they’re not.

[01:02:51] You know, if they’re a junior coming in that they’re going to ask a lot more questions. And that’s the thing that you’ve asked about, like, do you, that junior that asks a lot of questions. There’s different questions that you can ask. One question is I want to know more about the domain, the business domain that I’m in and you start asking questions.

[01:03:10] Well, okay. So they make an order and, and, you know, kind of, we have warehouses. Yeah. How does, how does the orders get to the warehouse? You know, that, that those are. Those are kind of, kind of domain questions and technical questions about how, how, how the business flows. But then there’s another kind of question that I think maybe, maybe you’re more, maybe you’re more thinking about which is, which is I’m trying to do this thing and I can’t get it to work.

[01:03:36] That’s a different kind of question. That’s a, that’s a, um, Here’s here’s the thing about those questions. I did have a junior that I worked with and I got these kinds of questions over and over and over again. And every time I’d get one, it would kill my, my, my train of thought for an hour. I would lose about an hour of time.

[01:03:55] Every time I got a question that would take me off of my project and. I really, I was the good guy. I wanted to go answer the question. I was the selfless, the selfless developer. If someone asks me a question, I was just elated that someone asked me a question. So I try to go answer it. And, uh, um, you know, the, it got to a point though, this is the one developer also that I would, I would give an answer to.

[01:04:18] And this developer would pretty much challenged me a junior level developer. I had like seven or eight years of experience and he would challenge me on it. And intuitively I knew why I was saying what I was saying. I’d been through his problem and I’m like, dude, I don’t have time to really go into in depth right now on this.

[01:04:36] This was a problem I had dealt with. You’re going down a path that might cause you problems because the path that didn’t, this is the path I learned from, uh, when I did it. As far as what didn’t cause me trouble. Cause I did it your way and it did cause me trouble. Well, I don’t believe you. And then you go do it the way that I basically said that caused me the most trouble.

[01:04:55] And so, um, That’s the kind, that’s what you don’t want to run into. You don’t want to beat that person. If you’re going to ask for advice, even if you’re not going to do it, don’t tell someone you’re not going to do it. And then they just spend all that time trying to help you. And, and, uh, you know, you’re, you know, then they’re not, she’s not gonna want to help you, but here’s the most powerful thing though.

[01:05:16] If you ask for advice, take the advice. And if it’s, you know, what, if it’s not stupid, like, like, like yes, murders, murders, perfect. Like just, if you have someone you’re competing with kill them, you know, that’s that kind of thing. If it’s not something really illegal, crazy, and you try what they told you and, and you come back and go, Hey, I tried the pattern, you talked about this way.

[01:05:40] And, and I noticed this and this and this, but you’re right. It actually did work. That is a really good conversation to have. Like that means you’re trying to learn something as a junior, from your, from a senior level developer. And you had a conversation about the aftermath of you attempting to use that pattern.

[01:06:02] You know, like I said, if it’s not something really dumb, like, like, you know, shave, shave, uh, what is it, uh, uh, a thousandth of every penny off the system going through the, going through the, uh, of money going through the system and put it into a checking account for yourself, even if it’s not that kind of advice.

[01:06:17] Try the pattern that the senior level developers telling you that it might be good for you to use, see what it does. And if you have an issue with it, have a discussion like, Hey, I tried this and I noticed this and this, or are you in better come up and say, I did try this. And it worked because that’s going to get you more help.

[01:06:35] And you’re not going to be considered, even if you are annoying. Like even if, if I’m. What I’m trying to convey the message I’m trying to convey here is that if you ask for advice and come back and say, I used your advice, and this is what happened, you’re going to get a lot more advice from someone who who’s been doing it a lot longer.

[01:06:55] You’ll become there without even asking about being them, being your mentor, anything you’re going to develop a mentor, mentee relationship without even asking for it. If. You get what I’m saying? No. Yeah, I totally get it. I think I was like, wait, what?

[01:07:18] No. Yeah, I totally get it. I think that’s a, that’s a, that’s probably a good place to, uh, To lead the conversation. I think we went, we, uh, we definitely had a lot of, a lot of different points. There was some there’s some great stuff. Anyway, guys, we have some great episodes coming up. Uh, we’ve got some more interesting people that we will, we will be interviewing as well as some great topics.

[01:07:38] To focus on, please send us your topic, ideas, um, go and sign up for the, uh, the newsletter. And you can reply to that with any ideas that you have, um, and also get notified about the podcast and when it’s coming out, um, Yeah. So thanks for, thanks for, uh, thanks for doing this again. This is, this is always fun.

[01:07:58] Remember that, uh, that website of ours, that’s a www.juniortoseniordev.com and that is where you can sign up for that, that email list and see our latest episodes and whatnot in the show notes. Thanks so much. Yeah. Thank you. Have a good one. You too.