Context is King in Software Engineering - Derek Comartin of CodeOpinion

So, this one's a super special interview for me. As a content creator, one of my favorite things is being able to sit down and talk with other software engineers in the creator space that I really look up to. My guest today is Derek K Martin of code opinion.com. Now, Derek and I talked through his career journey and we get to see how a lot of what he's been working on really influences how he's been able to come up with architectural patterns in his decision-making process. We talked about things like agile software development and being able to work in consulting and really shape your perspective on working with stakeholders and understanding how to communicate with them effectively. And Derek is very well known for being able to say context is king and really takes situations that you might have a very biased opinion about and walk through them in ways that get you to think about them from different angles because without the full context it's really difficult to make a decision. So, I got to pick his brain on that and see his thought process and how he can really channel that in basically every conversation he has. So, again, this one's super special for me. I think that you're really going to enjoy it. So, sit back, enjoy. I'll see you next time. Derek, to get started, I guess if you don't mind uh giving us a little bit of background for uh and you can kind of start as early as you'd like, but kind of where you got started and how you got to where you are in your career. >> Sure. Yeah, thanks. So, um I guess I'll summarize it, which is like I I live in the kind of the business app world primarily always working on larger fullcale systems that really run kind of a line of business. Um that's just kind of the lane I've been in. I don't I didn't necessarily like plan it that way. It's just kind of maybe geography, what was in my area, companies that I worked for. Um, it's just kind of always been that way. Um, so a lot of the stuff that I post, you can see how it usually revolves around bigger sales systems and that type of stuff. So, that's kind of where I'm at. Um, I've never I always tell people I've never really got into like other realms of like say like gaming or something like that and developing games. >> Although that's really what kind of set me on the path of getting into software was games. >> It wasn't. It was kind of like modding games, uh, building out like kind of websites that were like more tracking for like tracking purposes of games and stuff like that, like leaderboards and stuff like that. And that's actually kind of what got in my interest in it. But I've always kind of been in that line of business space. Um, so almost everything I post really revolves around that experience basically. Um, but in terms of like the companies where I'm at a lot of it, again, this is like no intention of any of this is has always not always of the vast majority of it has been startups. >> Okay. >> Um, the first company I ever worked for was a startup. The second one was kind of in the dot era bubble. That was a startup. Then the longest stint I had was actually working for um a company that was local to me but did across Canada uh more warehousing and kind of direct to consumer type products. Um so I did a lot that for a good eight years probably there. >> Uh and that was a big that was a big learning experience basically because it was a big system. It's like for warehousing. So, and then which I highly recommend to everybody and I just said this to somebody the other day after that I worked at a kind of professional services consulting company. >> Okay. >> And that was also another mind bender on how I viewed writing software decision making. Um because I say I I it's not for everybody. Sure. And I it's it's I think it's kind of a difficult world to live in a little times because there's so many factors that can affect your decisions. But I love the fact that it forced me to think about the business side of what people are really trying to accomplish. Uh and like the cost involved when you're estimating or basically where you can see I always tell people even if you're just doing it on your own. >> Yeah. and you did say project based work and you had to estimate the your effort and you can see the bottom line how that like really starts changing your decisions versus oh I work for this big company and I it never even crosses your mind on how you actually get paid >> right did you notice that like I I have not done sort of the consulting or the sort of the work on my own where I'm doing those estimations you know for for a client But I tell people like startup compared to Microsoft, I'm like I definitely in startup world had to think a lot more around like the cost of things or it seemed more like there was more awareness. Uh did you find like for being at startups that you still had a lot of that but obviously the consulting part like that would be a lot more visible because it's like directly in your control. >> Yeah, I would say they're they're similar. They're different like the the startup world the mentality I guess depending on what your role is in it. Um but if you kind of have more of a decision-m role >> there's this balancing act of I like saying like you're you're trying to make it you're making the best decisions you can to push forward >> like you're making a decision right now so you have a tomorrow. >> Yeah. >> Right. like you you not everything can be goldplated. Not everything can be perfect even though you're that's why like the the whole um mentality or people talk about like technical debt. I have such a different view of it because for me it is it's it's actually a explicit decision you're making. It's not like this accidental one for me. I never really think of it that way. It's like, oh, we just did this crappy thing, this crappy way, and didn't realize it till after the fact. To me, that's not really the case. It's more of a we're doing this now explicitly. We know this is not maybe the most ideal thing in the long run, but it gets us to tomorrow. >> Yeah. >> Which is a very different way of thinking about stuff, but it's more an explicit thing. I think the consulting thing is it's very similar. It's just you're more hype like you're just more aware of time. Um I can't remember the name of the I might be getting this wrong so somebody can correct me. It's called Parkinson's law I think is what it's called and I might be butchering this but >> it's to the effect which I find is has always been true which is if I told you you had tasks to do >> right and I gave you two days it would take you two days. If I gave you two weeks, you'd find a way to make that fit two weeks. >> Yep. And I think it I think it is Parkinson's law. That sounds familiar. Yeah. >> And I feel like that's held true all the time and I've noticed it the most like in in kind of that consulting project based world. >> Interesting. Yeah, that um it's a that's a very fascinating thing because I have seen it happen like maybe the sort of the the reason why it happens or the scenario around it is different. So like in startups it's it almost always felt like hey there's too much to do. So like the time window you have is very small and it's like okay like the work we're going to get done somehow is going to fit into this tiny box. And then I find uh like especially like at Microsoft in comparison the things move slower and there's many reasons for that. I don't say that to mean like therefore it is worse. But when things move slower it's like yeah there's times where I'm looking at the work for some feature or something and I'm like the complexity of that's not really that much. But the way we talked about this was it's going to take a week or two weeks and therefore it literally will take that time. Like it just fills up the time. It's very interesting. Yeah, it is fascinating. I remember thinking about it and once I actually put the there was a name to it and read about it, I was like, "Oh, this is exactly what happens most of the time basically." >> Um, >> yeah, >> but yeah, so like that that's kind of the world I've always lived in. And again, I think everybody's path's unique, and mine just happened to be a lot of the times because I was in startups, being in a position to kind of make more decisions about the direction technically of the products or projects that I was working in, which at some points I was totally unqualified for. Um, but you kind of push through and you have gained some experience from it. Would you say that uh like that's a very interesting statement especially because uh you know for people that know all of your material right like uh you absolutely come across as and I know this is things that have evolved over time and you've learned and gained the experience but you are you are an expert in many of these areas. Would you say that or sorry we we many of us perceive that of you >> and and we value the material and the learning opportunities from you. So when you make that statement where you're like, you know, was wildly unqualified for some of these things. Would you say at that point in time like were was that something that you were conscious of where you're like, "Oh man, I have to go push forward on like on this decision or this architecture, I'm responsible for it." And you're sitting there going like, "Oh man, like I don't know about that." Or was it more like in hindsight you're thinking back going, "Oh, >> yeah. I think I don't know. It's probably in in hindsight. Um, but my like at the time in any kind of like I'm thinking of one particular project in general which was kind of like a really big rewrite of something. Okay, >> that was some really old technology and I highly don't recommend rewriting things just like blatantly and I posted about this in circumstances where it can make sense. Um, and all the things that go along the way is that one of the issues with it has been like or with it is what makes you think you know kind of all the intricacies of the old system that you're going to be able to do that like what makes sense in the old system that you need to implement going forward or like what was there and doesn't even apply anymore. There's just a lot of history with things. >> Yeah. Um, so in that case, if you're unfamiliar with it, that can be very like that's just one aspect that can be very difficult. In my case with that, I was around a long time before I was a part of the rewrite at like probably almost 7 years. So I had a lot of backstory about where we were now or like at that time. >> Yeah. Yeah. >> So when I Yeah. So when I say I was very unqualified, that's the one I'm thinking of is like I was in maybe more of a technical sense, but not I wasn't in a domain sense like I unders I was there for for quite a while that I understood how the business operated and the changes that we made along the way to accommodate certain things. So, um, that's why I'm pretty vocal often times about being well aware about the domain that you're in and really understanding it. Um, one of the again like in this world of writing kind of line of business stuff, one of the the for sure the best developers I know in this space really understand the business, >> right? It's not it's not a oh I just know all these patterns and technical stuff. That is not it at all. I' >> repository patterns here factories here and we're good and problem solving. >> No, it's probably almost the reverse where is like if you were to say like what are they better at like technical or kind of have that business sense or in that domain. I'd argue it's probably they're a little like they're very proficient technically but actually probably have a little bit more um I don't know what to call like just business sense like they really get it and they get the domain that they're in and they can speak the language of stakeholders really well. They're not um super like it's I don't want to say they're not technical because they are >> sure. Yeah. Yeah. Yeah. It's just they have this really good skill set of understanding workflows, understanding business processing, and really getting involved in it. There's for sure the best people I've worked with that are that way. >> It's interesting, right? Because like um a lot of the time or at least when I'm talking with software developers, like one of the things I try to highlight is with technical skills, these are things you're going to be working on these your entire career. It's I I don't even know if it's possible that like you're going to be getting worse technically in your career because there's always stuff that you're going to be working on, but I especially for for more junior people, the thing that I try to highlight to them is that you don't want to ignore the fact that if you want to continue to grow as a software developer, the sort of the the communication part like working with other people, understanding stakeholders, that's the kind of thing that like if you if you think that I'm going to be a programmer and I'm just going to like kind put my programming hat on and go heads down and just code all day and not work with people. Like that's dangerous because it's it's just going to be so limiting in your career that and it it sounds like what you're saying is kind of resonating with that where it's like the people that really excel are the people that that can work with those stakeholders. >> Yeah, for sure. I think I don't know like I think it just depends maybe your environments like places that you're in like cuz what I should mention earlier like being in consulting for a little bit there is like you have to like that's at least the world I was in you're you're you're doing kind of when people talk full stack I'm talking like you're talking to the client you're you're coming up with estimates you're coming up working with a project manager you're actually working as the developer or part of the team or leading it it's like the full gamut of stuff so it's not just like you said, it's not a single hat of, oh, I'm just writing software all day. It doesn't really work that way. But again, that's just kind of the world that I've been in. To me, that was that was super beneficial. It gave me a lot more perspective, >> right? >> I guess a lot more context on the stuff that you work in rather than just, oh, like I don't really know who the end user is that's going to write to use this. It's it becomes I guess I guess in some ways it makes you or like for me it maybe less concerned about certain things and I think that in your little bubble of like oh I'm just writing I'm developer writing this. I think maybe in that context because you're just in that you get a little bit more fixated on certain things that are important to you but at the grand scheme of things don't really matter. So I always say like it's in context here. I always say that but like for example um I say it all the time which is let's say you're writing again like warehousing software or something like that. person in the warehouse that's say printing out a shipping label or you know what I mean shipping something out or receiving something. They do not care that you're using X technology or X framework. They do they want the thing to work. They want it to work well. They want it to be intuitive. They want it to do their job and they don't want it to get in the way. That's their end goal. So you could say that yeah it does matter what technology you're using because but it's a means to an end. So if you're using X technology and it's outdated and you can't move forward with it then yeah that's a problem for that end user because you won't be able to keep up or be able to do things that make their life easier. So it all goes handinand but I think there's a little bit sometimes getting fixated on some technical stuff that developers love that just really don't matter. >> Right. Yeah. And I think that you said it really well where like a lot of that stuff it can be a means to an end, right? Like you're picking a technology, you're picking a stack, you're picking architectural patterns that that help you achieve that, but truly the end user, they don't know any of that. Like and it doesn't matter. Um it's but yeah, it's a means to an end. So >> yeah, like I know people are thinking like yes, it does. I'm not saying it totally doesn't matter because it does. There's a lot of factors to Yeah. like what you're choosing, how um how well that lets you move forward or iterate on things, like it obviously matters, but at the end of the day um like if you have a product written innet and some like C and somebody has the exact same product written in I don't know Ruby on Rails or Python or something like that is like is one fundamentally better because it was written one way or like in one >> right >> tool or another? probably not really >> like are customers making that like that purchasing decision or that using usability decision based on they're like I got to go research which language this was built in or else like I can't use it. >> And that's the thing is that like I I've posted things like this and people say yes. I usually put the asterisk of like if the people are like if you're selling to developers they care. >> Yeah. Yeah. >> Right. Or maybe if it's a certain type enterprise and they need to integrate a particular way they may care about some things like that. So yeah, it's all within context, but at the end of the day, like if I think of like some product that I use, I'm just looking at my bookmarks. >> Got to look around to see what's what's up on screen, >> right? Do I ultimately know or care what this one service that I use is for whatever? Like some >> I don't know what Gmail's written in. I don't know. Um I we're using Streamyard. I don't know what Streamyard's written in. It's working. >> Exactly. Like do do you care? No. You want it to work, right? and you want it to solve your problems like and as long as it keeps getting updated or features that you need and it's evolving and the underlying technology allows you to do that then whatever like doesn't matter to me. >> Yeah. >> Huh. Okay. So you had mentioned too that uh when you were kind of walking through some of the career journey part you had ex I I don't remember exactly how you said it but you kind of paused and you said I actually recommend this to everyone but so do you recommend that people have some part of their of their career where they do get exposed to uh like consulting and I I know you were saying it's not for everyone but did you mean that like at least to kind of learn that about yourself or to >> Yeah. I think if you're if if you're I'm just going based off of my own experience of looking at like the world I live in and kind of like line of business stuff. It made a world of difference. Like that was a t that was like a very key aspect of my career was doing it. Um because like I said because you just are it changes decision- making a lot. Um and it especially in terms of if you want to get more into like okay the aspects of say design and how you're designing systems it affects it a lot because you like I was alluding to earlier um the different constraints of just physically knowing the cost of something and both sides of the equation of okay like what's revenue what's cost all these implications and who's paying for something And um it just it it makes you much more aware of your the whole situation that you're in rather than like I said earlier just oh I just have this one task from whatever Q system or whatever we're doing sprints or >> some com on board and like I'm just pulling a thing over and just do it and it doesn't really matter like you don't really think about the implications of the the time constraints of it if is um is it really even worth doing? >> Like how much effort to put into something if it's like because that's the thing in any system that you're building, right? There's kind of that paro 8020 and most of the time you're not in the core like you're kind of on the outside making stuff that like is it really even going to be used? What's really the value of it? >> Right? >> Um you can assume that oh yeah, this is this thing's going to be awesome. functionality that we're adding and then like nobody really cares, right? So I think that as that's why I said I think it's useful. I think every I got so much value out of doing the consulting aspect of it and estimating and working through projects and working with the project manager even to that effect you could think of like that it's not really your role but you're kind of like in everything. I just I found a lot of value in it. That's why I think anybody that's in kind of that line of business world where you want to be designing systems, building systems, kind of green field up something bigger if that happens to be in your path. I think it it would be very beneficial, >> right? >> Um I say it's not for everybody because it's a lot more mentally taxing. >> Yeah. >> To put it that way. Like I guess maybe depending on your personality like if you're a ve for myself like I'm very I want to be on the ball. I I I'm very concerned probably more times about who like the stakeholders are probably more than they are themselves. Like I it's like a very personal pride thing. So you don't want to be wrong. You don't want to be doing the wrong thing. And there's just this weight of like uh making the wrong decisions. Mhm. >> But in that you realize you can only make the best decision that you have at that time with the information that you have and you really become just out of this kind of analysis paralysis and you really and again because of the startup stuff you really iterate, push forward and move forward which I think is a good thing. >> Yeah. Like you have you need to be making some decisions so that you can take action. >> Um but yeah know it's really interesting. I think the the way you're describing that is like um I've often said and I don't know how I quote myself or whatever but um one of the things that I I try to bring up to people is that when if you don't have constraints right like you can you can come up with you know limitless solutions and you know what does perfect look like who even knows but when you start putting all these constraints on and that includes time that includes like you have systems that are already operational right like some there's a live service running and now people want to rewrite it and it's like what does that even mean and you got to do it in you got to do it in two weeks like when you start tacking on all these constraints you get you have to start getting extremely creative with the engineering to be able to facilitate that otherwise it's like okay there's no time constraint okay or there's no live service that's running and it's a totally green field okay like you start having all of these options and I feel like the I don't know I feel like the creativity part kind is lacking when you don't have those constraints. >> Yeah, I think so. For sure. One of the You're making me think of this. One of the things talking about constraints, it's a different kind of way, but I always called it um just giving yourself options when you're designing things. >> Um and when you were talking about this, you made me think because I I was just I didn't have a term for it. I just like for options. Um Aaron Stannard um he calls it optionality um and he has a few different blog posts. I've done this on this too. It's we talk about the same thing which is just giving yourself options that are low cost when you're kind of building systems. So it's not again like it's not goldplating. It's not building out this highly configurable thing. It's just there's certain things that you can do um that are generally low cost that give you options through kind of any kind of long live system. Um and I think you kind of start figuring that stuff out what those options are um through just making just having to make decisions um and forcing yourself to like okay I got to go this route or this route which one gives me the most options at the lowest cost. I don't think it's like a necessarily like um like a thing people are immediately thinking of. Um because oftent times like I'll get questions on YouTube or anywhere about I'm giving the exact this seems far powerful what I'm saying but >> people often talk about like domain driven design y >> and they'll talk about they get I say this all they get fixated on kind of the technical people call them like the tactical patterns of repositories and all these things or how you're supposed to do something and they get so set on how do I do this like based off of domain design and they get so fixated on that that they lose sight of like what they're really even trying to do and they're actually making things more complicated than they need to be. Um, so the options part of this is that is just realizing I guess the systems you're building, what you're building. Um, don't guess the future for sure. >> Mhm. >> Um, but it's still there's there's things that you can do to make your life easier because things will evolve. So to make that more concrete for people rather than just a bunch of nonsense um that are really easy is just really understand it's tough but really understand what I was talking about like your what business you're in what line of business what domain understanding and understanding kind of like the really the workflows of what happens in a system because most oftent times pe when anytime building features often times you can probably relate to this is people will bring up the solution to you. >> Mhm. >> Rather than actually the problem. >> Yeah. >> And then oftent times the pro like their solution to the problem. Um most times the problem is really superficial and it's actually more deep deeper than that or it's like a workflow process thing that really indicates really what the solution should be, >> right? But it just becomes a superficial solution on top of like a or like a band-aid to a problem that maybe you don't really even need to have. >> Yeah. >> So, if you can start figuring out some of that stuff, um the technical aspect of it is it really does relate around that. So, when we're talking about like a repository or something like that, like let's say abstracting your database. >> Yeah. >> Is that is that a good idea? People would say, "Yeah, that's a great idea." My my answer would be I don't know >> because I don't know the context. Like do you need to abstract your data? Let's say for example, you had a really tiny CRUD app around like I don't know a couple entities or tables or data models and you if you were to like look in the source code and you see oh well there's maybe I don't know a dozen calls to the database do you really need to write some abstraction around a dozen calls >> right where the the amount of abstraction is going to dwarf like the number of calls to the database. >> Yeah. So like oh well we could cuz we want to abstract this so we can test it easier. You could still test like there's different like the testing aspect is one reason why you choose to go down that path but just blatantly say oh well I need it could be anything. Let's say uh yeah some type of like blob storage or something like that. Let's say you're using >> some Azure service or AWS S3 or something like that. It's like do you need to abstract it? It's like well depends how many usages I have. Like what's if there's 10 that's very different between 10 and a thousand. >> Yeah. >> Right. So everything plays into kind of when you're when you're making decisions about like where's the value in the system? What are you working on? Um and not having to be so I guess what I'm really trying to get at is just being a little bit more pragmatic. >> Yeah. just so rigid about, oh, I need to follow this pattern or I need to do this and I need to do it in this way. Um, because there really just isn't, it goes back to the whole silver bullet thing. It's just like there just isn't. So, >> right, >> the sooner you can figure out maybe what the best options are and roll with it and being very reflective about what works and what doesn't. Well, and it sounds like from something you said earlier where you're saying some of the best developers you've worked with have a lot of that domain knowledge. being able to channel that plus adding on top of that the experience of like I've seen seen these types of things enough times to go okay like for myself like yeah like have I abstracted databases too many times like yep like I have definitely done that but now that I've seen it enough times if I'm working in a domain where if I have a lot of knowledge around that I can start making a more informed decision to say like something like you were just talking about to be like do I need to really do that and it's actually maybe like maybe there is a good use case in this domain where I should be considering that. But because I've seen it enough times I can understand what the cost of doing that is in the codebase or or make an informed decision around that. But I think like those two things like the domain knowledge and then having some of that experience of having seen it a handful of times can help with that. >> Yeah. I mean that's the thing I find difficult to explain to people is like it's just experience some of this stuff that you're getting at. It's just like seeing enough of it. Um, and that's where some of the consulting part, I guess, plays a role into it because you're you're in different domains. You're either a part of kind of new projects or existing things. >> So, you just get a lot more Yeah. You just get a lot more experience in kind of a shorter window rather than if you're just working on a singular product. >> Yeah. >> Right. Yeah, >> that's I found even a similar thing like working at a startup because well we I mean at the very beginning it was one product but then we had several and there was like different you know uh same domain it was all digital forensics but it was like what we're doing and what we're building are different pieces of this. So then you start getting exposed to different things or a new product's spinning up and they're like we're going to build it this way and we're like wait a second like that's not the same and then well let's let's consider that and like what do we learn from that one? So then the next product spins up and we're like okay now we have more data points but you have to get exposed to some of these things before you can start like feeling like you can make more informed decisions. >> Yeah, for sure. And I think when I go back to you saying like I felt like in certain spot I was wildly unqualified. I don't think I knew it at the time. >> Okay. >> Um in hindsight probably for sure I did like well I do now. Um, but like I some of the decisions that I made that I know were um probably poor ones weren't weren't like project breaking, product breaking, like horrible things. They were more so oftent times about the way I I this is a really good example. I lacked understanding of what the end goal was for the business. Like I didn't really have a good clear enough idea of what it was. So then the technical decisions behind that might be problematic. I'll give a really kind of weird example. >> Sure. Um well the some people that can somewhat understand is that so let's say in a warehouse um you can think of like shipping receiving distribution so you have you're ordering products from some type of vendor manufacturer you receive that in your warehouse then you may be shipping that out and selling that to consumers or businesses whatever the case may be. um all of the actions of receiving product um doing the different actions of like inventory counts or shipping product out that like that whole big they're they're kind of processes under a larger process. There's a bunch of processes that kind of chain together or kind of work together. And if I understood that sooner, um, it would have made other parts of the system easier, less I would say less complicated. >> What I mean by that is like let's say you were just counting, let's say you needed to keep track of inventory. This is like the common example people always use >> is okay well I received product into the warehouse from the manufacturer or whatever and then I shipped some out and I had some break. So like there's some number in the system that we have that's like our inventory for that particular product. That would be I think how most people naively would think about inventory of like I need to build an inventory system. >> That checks out with me and I know nothing about inventorying. >> Exactly. But like that's the thing, right? It's that if you were just kind of nonchalant doing this that seems like on the surface what it is. >> Sure. >> The reality of it is that's not the case at all. Is that the actual number in a system of like, hey, we got 47 of this widget means nothing. Like that's not even really a thing in an actual distribution because what what is the point of truth is physically because we're talking about physical goods is actually what's in a like what's on the shelf somewhere in a warehouse. Like that is really what it is. So then you say well you still need a number in the system so somebody could look at it say oh we got like 40 of these things left is that yeah but it's not really the point of truth. It's just a number that's representing closely potentially really what you have. >> It's not you don't really actually make hard decisions off that number. >> Yeah. The source of truth is the shelf, right? Like that which physically is there. >> Yeah. So, for example, you wouldn't have a business rule that states we cannot oversell like there's only 40 if somebody tries to like we get down to one. It's not like um for example like concert tickets or something like that where like or you're going to an event where there's like a limited number of seats in distribution. It's like okay there's one product left. Okay, you can sell three. >> Yeah. >> Because it's not I it sounds weird is that you It's not that you can't sell more, it's that you need to purchase more. >> Yeah. It's like a pipelining like process like all these That's a really interesting point. It's that's making more sense now. they're chaining together to >> Yeah. So that's the thing is you're purchasing more so that you can sell more and then the number for sales like what really the number they care about is really just kind of that roundabout number which also triggers purchasing and okay I need to buy more and there's kind of processes around this but it's again like superficially you would think oh like the the quantity on hand really matters. It's like no it doesn't. Hm. >> So that's the business part of like because if you think technically if you were implementing this, >> how would you keep track of all this? >> Well, yeah, based on what you said originally, it would be like I need a count in a database like I need what's the product ID, what's the count, and got some things that make that number go up and some other things that make that number go down and problem solve. Right. >> Yeah. It's not that way at all. >> Right. And I know like we're talking about like a actually a complex domain and we're making it sound simple for example and that's that is the case but I do remember at the very beginning being in it thinking exactly the way I'm describing is like oh there's some count like exactly what you're saying like that seems obvious but >> it's not really that way and if if you understood kind of warehousing like anybody in a warehouse would be like well that's this yeah no it actually works this way and then you'd be like oh okay that makes entire sense. >> Yeah. Um it's the kind of the same thing with accounting. So I one of my mentors um kind of in that consulting phase was actually an accountant. >> Okay. >> Um that makes no sense probably. You're like hey you're software person and >> what were his architecture skills like? Yeah. >> Yeah. But it made it made a lot of sense because um they thought about things very differently than I did. >> Okay. Um, and the way that even when I would talk to them about just the projects I was working on and things I was working with, they just had a very different way of thinking about it. Um, so that's the one of the kind of the the benefits I guess in consulting is that if you are working in different domains, you'll start to see the overlap of them. They're different obviously like there's so for example you would think like oh um let's say software project work like you're like not product based I mean project based type thing where you have some client need something get built out you kind of however you want to do this whether it's obviously something iterative still but there's still some scope to the whole thing. >> Sure. Yeah. the that in say a project based work for let's say um construction like building a house or building something for in the automotive world because that's where I live near Detroit here. >> Yeah, >> they're actually very very close. like building software and say building a project like a mold for some part on a vehicle are actually very very close. >> Okay. Interesting. >> Well, that's the thing is but you wouldn't think it unless because it's really the project based work nature of it that the underlying kind of what you're actually doing is very very similar. >> Interesting. >> The iteration is very similar. Um there's obviously differences, but they are still very similar. And once you kind of see it, >> right, >> it's kind of hard to unsee it. So when you're in one domain and you're in another one, you can start seeing the the similarities, >> right? >> Um and I'll give you an example of this. People are like, "This is a technical show." Yeah. But but I'll give you an example. in kind of the manufacturing world, like project based manufacturing, like especially for automotive, is they may, let's say, like a mold for a bumper on a car, you'll have a quote come in from one of the auto manufacturers to uh one of the companies that's doing this and somebody will estimate that, how to build a mold for that part. Those estimators are extremely experienced. They have a lot of historical knowledge about other like other projects they had that are almost the exact same thing. So they really can rely on history, their own knowledge, the knowledge of the person sitting next to them that's the estimator. >> They have this a lot of historical information about what something might cost and how long it would take. So they're going through that bidding process. Um what then happens is once they kind of do the work and you go through actually operationally getting it done there's all this cost associated material time and what happens there's a feedback loop that goes from kind of the end of the project of did did the company actually make money on this part >> to build this mold so that the next time you we get in that same similar bumper for a different year a new model year it's like what did what did we quote last time how'd that go like you can build based off that history Right? That exact same thing exists similarly in transportation. >> Okay? >> Where you it's the same thing. I need you to urgently move some freight from point A to point B. And they they might call that like a lane. Um it's what did I do it for before? What vehicle like what what's this like what vehicle type is pricing is based off what vehicle you might use. There's still this feedback loop. It's still kind of project based. It's a one-off thing you're doing, >> right? you're shipping something from point A to point B, there's a rate to that and there's this constant feedback loop because the rates are always changing. So once you kind of see the similarities between manufacturing a bumper, >> right, >> to shipping a one-off product, having a shipment, they they correlate a lot, >> right? And then then the extension to that is then you go, okay, well software now we're building features out and >> Exactly. So it's like how did you implement for example um a certain part of a workflow because the data might be similar because now you start thinking okay I can see how these like how data in that world is similar to this world because it's like this is this transactional stuff here that's in the same type of loop that's over there and what does that look like? Um, so then that's where the technical aspects of it comes in where you can start seeing maybe this is how we're going to implement this part of the system because not all part like not everything in your system has the same value. >> Sure. >> Right. So it's like there's some stuff that's just CRUD by nature and you're just whipping on a UI over top of a database. >> Right. And then there's some parts that are really workflow process driven that will look completely different and you're not going to implement them the same way you like at all. You may not even store data in kind of the same type of way. Um so I think those experiences seeing different domains hopefully now I've explained enough of it where people can see okay that's why understanding business process and all stuff will really shape >> technically um the decisions that you make. Yeah, >> because it's not all just Yeah. UI on top of a database basically. >> No, and I really like the examples too of taking like two like two things that are completely not software and kind of illustrating that like even those are you know you can compare those and it's it's interesting. It's like a forecasting type of thing, right? Like you take historical information, you forecast out and then >> and like is it going to be perfect? >> No. Like nothing's ever perfect, but like you use the information you have, make the best decisions you can, and then have a feedback loop so that you can try to make a better decision in the future. So >> very cool. >> Yeah. And I mean, is that really different than say project softwarebased work >> like like iterations through say whether you're doing scrum or something else like you're doing some iterative development. >> Yeah. Like what comes to mind for me is like I I think the thing that makes it more challenging and I don't know anything about the two other industries that you said. So like I'm I could be completely out here but I think when it comes to software um I find that people including myself people find it harder to sort of quantify uh like the amount of effort like hey yes I have done this before but if I is it a direct comparison like it starts to feel a little bit handwavy and that's where I can see people kind of get into the weeds of like well especially if you're doing story points and stuff like no that's not a five that's now a seven it must be a seven. It's like, okay, maybe we just need to go build it. Like, >> yeah. >> Yeah. No, I just I think I think there's a lot of that translates to it. I think estimating is really difficult, but I don't know. I kind of have a little bit of a gripe of it was more of a kind of a combative conversation. It probably still is. I just don't pay attention to anymore. I remember years ago about like all the how estimating is impossible and I never really thought it was impossible. It was just I think of maybe at the scale of what people were trying to estimate things. >> Yeah. >> Um but yeah, again it's just experience I guess. >> Yeah. It it for me it wasn't an impossible thing. It was more like when we're getting so trying to be so granular on things that we cannot be that granular about like how much time are we going to waste on this like because if we were to stop talking about this we could have built it by now. Um like that's where it starts to feel very terrible for me. Um but in general like I can totally understand that especially if you're working with different stakeholders it like you have to think outside of of the programming bubble to be like okay like other people are going to rely on this. There's going to be end users. There might be other teams that have to build on top of this. There's sales and marketing that probably need to know what's coming down the pipeline so they can start talking about it. So just sitting there going like can't estimate it. Like it's not really a it's not really fair for a business. >> Well, that Yeah, that's the thing because I always thought again going back to consulting stuff is somebody's cutting the check for it. >> Yeah. You need to know what they're paying for >> and relatively like what they're getting for it. >> Yeah. >> Like nobody It's It'd be like you like, "Oh, I need a new roof on my apartment or house or whatever the case may be." It's like the person's just like, "I don't know." >> Yeah. It's >> I don't know what it's going to cost. It's like >> we'll have to see once we start like and it might Yeah. Well, we'll just see. >> It's not going to work. I need a roof. Like I know it's a bad comparison because people be like, "Oh, like it's a little easier." I get it. But my my the point is still you generally as kind of the one as a consumer of it that has to pay for it. You and no matter what it is, you you still want to have some insight on what the range is. >> Sure. >> Of what you're get getting into. >> And I think that's an important part, right? It's like I think a lot of the time when people get into estimating things and I I don't know I'm kind of going back to some of my earlier career like when I remember sitting down and like in these meetings with story points and stuff it felt like people were trying to find what the perfect estimate would be which doesn't even make sense but what you just said was like a range and I think if people could start thinking about that more of like if we have some range where we can feel we can all leave the room feeling like that seems reasonable and then on top of that you can talk about like mitigation strategies or communication strategies where like you're partway into that. It's absolutely not going to be that timeline. Okay, not the end of the world. Everything doesn't just turn off. Like what do you do to communicate that? Give people the visibility like the stakeholders that care about that. What are you going to do now? Because if you're just like, well, we're offtarget and I guess that's it. We're we're cooked here. Then like then yeah, everything's going to fall apart and estimating is going to feel really bad. old. >> Yeah, there was a post Udy Dhan has a post. It's I don't even know how old it is now. >> Um I'll send you the link to it, but >> yeah. Yeah, >> it's it's I'm kind of well I am paraphrasing here, but it's something to the effect of the template for it is he describes why, but it's it's you know what I mean with you know what I If you say let's just yourself or however many people this many people or just myself >> working this often on it um like in terms of like how because obviously people have meetings or potentially another stuff um with this level of certainty this is what you actually think it is like you're qualifying it you're putting context to just some number rather than just like oh it's this long. >> Yeah. It's >> like what does that even mean? Right. So it's it's really just about qualifying what kind of your estimate is. >> Um but the other thing too going full circle here like the consulting thing in in estimating too is it's opportunity cost. It's like what are you actually working on that maybe isn't like like I said not everything has the same value. So it's what do you think something's going to take? And it it doesn't need to be like you said perfect. Not at all. It's just it's a little bit better than a grenade on like oh this is a big deal or it's not a big deal, right? >> Yeah. And it's so often too that like like especially if you're doing sprint work or anything like that like people set out with something in mind, you get a couple days into your sprint or whatever and someone comes by and they say plans have changed. >> We this is now the highest priority thing. Like these are very especially in startups very common conversations and then being able to go back to who that stakeholder is. So say it's your manager, say it's a product manager, whoever someone who's trying to influence the direction of what's being developed and going back to them and being able to have this conversation of like here's the things we're working on. You're now asking for this if we do a similar exercise like truly do you do you still think that's a higher priority? If so, like again, if it's a startup, like this is what the business needs to get to tomorrow or to next week or whatever. Okay, so what are we trading for this, right? But people can start making those more informed decisions without that and no estimates or anything. You're like, well, h how do we even make a decision about what to trade out of this if we have no idea what's even going on? >> Yeah. Yeah, I think there's this little tooth, this little bit of feeling that developers get of wanting stability, like wanting thing just like this is the plan and we're sticking to it and it's like >> there's nothing wrong with it changing like you're saying like okay, we have this this is what our kind of our quue looks like or sprint looks like and you know what in two days from now it might not look like that at all because something else changes. Maybe we got a new customer that needs this for some reason to onboard. Okay. Like there's it's it's just doesn't need to be that fixed. >> I think so I 100% agree with that. And one of the things I wanted to to share related to that is that I and I don't know if this is actually true but an observation I have from going from a from a startup where most people were just like we want to do what feels like the right thing for the customer because we're a lot closer. I find that in uh again don't know if this is actually accurate. It's an observation. I find that the incentives for individual developers at very large companies seem to be very much tied to the specific work they're doing and I and I don't like it. Um not that I'm blaming the developers. I think it's part of like the the system that we end up forming, but it ends up being like, oh well, if I can't work on that project we talked about, then like what's going to happen for my career progression? like that like it's it seems like it's very motivated for like I need to to have this thing or else or else I'm the one who's at risk here. And I always try to remind people like that's not the like if if we're talking about a project you're going to work on and it has to get canned or there's something that comes up where a dependency on another team is not going to work. I'd never want a developer sitting there going like, "Oh my god, my career is over. Like I'm not I'll never be promoted. I'm gonna get demoted." It's like, no, there's there's other work. Like, there's lots of work. >> Yeah, that's really interesting. I I mean, it totally makes sense to me what you're saying. I've never experienced it cuz I've never really worked like that in that type of environment. And again, that's that's the interesting thing is like everybody has different insights and it's that's interesting to hear because that that totally makes sense. >> That's why I said I totally agree with what you're saying because I don't personally have that. Like if my my manager came to me and he was like by the way one of the feature crews that you have that works in this area like we don't we don't need that anymore or that's moving to another team. I wouldn't be like my career. I would be like cool like someone who's making a decision around the importance of this. I would be curious about it of course >> but like I'm not going to freak out. it would be like cool now I can go focus in these other areas or I would be asking him like is there some other part that you need me to go take responsibility over um but I think that's be personally because my experience at a startup was very much like all of the time things were all over the place and it was I I want to call it organized chaos but I don't even know if I can call it organized it's >> just fluid >> yeah I I would say organized chaos is like it's pretty that's I mean it can that way for sure. >> So Derek, we're getting close to I want to be respectful of your time, but I I had one thing that I just wanted to touch on with you because um in basically all of the content that I see you either post or talk about on YouTube. Um you have an incredible way of uh like in my opinion being pragmatic about literally everything. It's like uh I find that when I personally go to talk about topics and if I have an opinion, I literally pause like in my brain and I have moments where I'm like I will literally say in my brain like how would Derek like try to get like different perspectives on this because I I don't like talking about things like there's only one side to it because I don't believe that ever. I always think context is important. And I think that there's different angles to a situation that might look the same. And I just wanted to I don't even know what question I'm trying to ask you here, but I wanted your take on like >> how do you channel trying to be pragmatic like in everything you do because you do it so well. >> I have no idea. No, >> it's magic. Um >> like do you consciously like do you have to stop yourself and be like I need to like you know think about this a different way or is it more natural >> just from it a lot? >> I'll explain maybe maybe I'll come to it if I explain how I come up with like >> a video or a blog or something because I think that may give some insight on how I think about things. So >> never mind how I get the idea. oftent times it's just I have a list going but >> sure >> usually what I do is I once I've set in stone okay I'm going to do a topic like I'm going to do a video or something on this topic it is I just think about it quite a bit and probably historically put a similar like think about a situation that I'm in that it applies to every topic I've covered this is probably why so like I'm rubber ducking Perfect. >> It's because everything I've done like I I don't know if there's one topic I really haven't that isn't something I've experienced. So it all comes from that place really. So it's not like um oh I want to use this technology and I'm not saying there's anything wrong with that. I just I don't that's not really my lane of like, hey, I'm going to look at like try this technology out and or something and I play with it and then do a video on it. It's usually about problems or things that I've faced indirectly through the topic. So that's usually where it probably all comes from is that I pro so like the the trade-off stuff is probably because I've experienced both. >> Right. Okay. Yeah. And and even even if you haven't lived through both necessarily, I'm suspecting that if you had a topic, you're like >> we we at least debated these things or we analyzed these things. We went with one and we saw this this outcome, but we had to go talk about all the other sides of it. >> Yeah. Like I'll give an example. So um earlier I mentioned about like abstracting a database or something like that. And that one probably hits home to a lot of people or maybe not. I think that one's probably the one they think about the most or topic that comes up is like oh do should I abstract this or not abstract this is that the so in 2015 um was not net core orn net as it is today did not exist yet um I I want to say about 2015 you you might know this more than I do um was what did they call it first like v- next or something like that. >> Uh there was uh there wasnet uh they had like standard or something like >> they had a moniker for it but anyways wasn't really it wasn't really wasn't a thing yet like net core 1.0 was not a thing yet. >> Okay. >> But I was well enough aware of what was going on and we were I was using .NET Framework 4.8 on Windows basically. Um as Net Core 1 came out um and then .NET Core 2 and ASP.NET Core 2 at that time. This is probably like 20, I don't know, 2018 somewhere around there maybe. I'm getting my dates. I was just very well aware of the size of the product I was in all using .NET Framework and how we could transition to .NET Core. And there was a lot of technical stuff and it wasn't a big bang. It was a small incremental changes that we had to make along the way. >> Mhm. >> And there's a lot that I learned from that and as the example there was net framework or sorry entity framework and then there's entity framework core um and there were changes all over the place um related to different third-party libraries we were using and yeah like you mentioned with standard. There was a lot of technical stuff going on at that time and that taught me a lot about uh kind of the abstractions that we had in our system, what was useful, what wasn't. >> Sure. And as an example, one of the third party libraries we used um even it basically underlying changed like pretty significantly the API surface that it had and we maybe had usage of this in a large system maybe let's say I don't know 50 50 places maybe made a method call now that did not exist or changed a little bit. Um actually it was worse than that. It was this is what it was. It was a non asynchronous call that turned into a synchronous call. >> Oh, okay. >> So, that can get pretty viral, right? Where now all of a sudden you have to await something and your whole call stack. >> It's only your whole call stack though. That's fine. >> Yeah, it's only the whole thing. No problem. >> But the reality of it is is like let's say those those 50 places or something that it affected, it really wasn't the end of the world. >> Um the way the rest of the system was built like the call stack wasn't huge. So it just it didn't matter that much at the end of the day. >> If it was abstracted, it would have been almost it would have been quicker maybe. But to go now, let's go abstracted so we never pay this cost again. It's almost like >> Yeah. It's kind of like Yeah. It's like a So some of that is often what I preach is just um like to the specifics of abstractions, knowing when you need it, what the value of it is, and not having it isn't the end of the world. depends on the degree of coupling that you have to something. So like the trade-off so when we talk about like the trade-offs of stuff and thinking about it, it's because it's just experience of being in a situation where maybe something wasn't. Would it have been helpful? Yeah. Was it a big deal that it wasn't? No. >> Right. >> Right. Like we it still we were still using interfaces for it that made it easier to test, but like the underlying like it just it changed. >> Yeah. >> Was it the end of the world? No. So that makes it you kind of keenly aware now of like when you're using a dependency like what's the degree of coupling that you have to it, how important is that thing? Um where is it being used in your system? Um so there's just like a lot of things that you can start seeing as tradeoffs that there really isn't necessarily at first glance sometimes a right answer, >> right? >> And you can see I go this way, maybe I go that way. There's just trade-offs. >> Yeah. And I have a really good example that is the opposite and it was terrible that I made a decision about and don't don't hurt my feelings here, but I um I was like I need my own eyeloger interface and I need that because I don't trust anyone. >> Like I don't trust that the API like I I need to basically have that level of abstraction between myself and everyone else. I need that because if I'm putting a logger in places, the service area is going to be incredible. Like if someone changes that API, I am totally screwed here. So for a long time, it was like new project I logger interface that I dream up gets put in and then if I, you know, if I'm picking a logger implementation, I wrap it. Great. Now I'm totally protected because I only have to change it in one spot if I pick a different logger or they change their API. And then what I realized over time was like the logging APIs just do not change like at all. If if anything it's like instead of like log debug, it's just like debug instead. Like it's so trivial >> and I'm going why am I doing this? Because now if I want to go switch to like a newer logging framework, I'm doing more work to try and wrap this stuff up with the dependency injection. It's I'm like this is so dumb. Um, and it's all because I wanted to force myself to have this separation. >> I think that's what you're expressing there is super common for people that they want to own kind of the the the abstraction. They want to own it rather than something else. >> I think that's a pretty common I would guess it's a pretty common reason >> um that people want to do it. But I always say if you're creating an abstraction what's that? >> So maybe not with loggers but yeah. >> Yeah. But like most times it's I think for that reason. Then the other one is if if you're creating an abstraction or anything based off an imple the the like a singular implementation that you know you're creating it just around that. So if you think that you're all of a sudden your abstraction is going to fit something another implementation behind it oftentimes it doesn't. >> Yeah very very good point. And like I think at the point and I don't know why I stuck with log fornet for like so many years and then I remember like waking up and being like wait a second there's a million different loggers. But um yeah like you're exactly right. I I was like I use log for net. I'm basically just going to almost clone what their API service looks like and I'm like now I'm safe like >> but I hadn't actually explored different things now. Like I personally build a lot of plug-in systems and that ends up forcing me like the first few plugins I put together I'm like the API is terrible. Um and then I build a few of them out and then I see the commonalities and now it starts to get a little bit more solidified. But it takes examples >> before you can start to get a good abstraction. So >> yeah, I think it's I yeah I think those are pretty common examples. Yeah. >> And I always say too is just Yeah. where they have value as well as um you're you're the for me the always the purpose is to simplify whatever I'm using for a given use case. If I don't have a use case for it or I'm not trying to simplify it then I don't really want to know what I'm doing like what I'm creating it for. >> Yeah. And I think my logger examples is me kind of focused on the wrong thing. Like you being hyperfocused on like what if what if that breaks? >> And in in hindsight too, if that would have been the case, it would have been like probably just renaming log methods. Like it wouldn't have actually been >> you could and half the time it I've done this before, too. It's just you rip it out. You create some extension methods or some shims to fill in the void. >> Yeah. >> And you're off to the races. >> Yeah. all the all the information or dependencies I needed were still present in all of the areas that would have used it. So >> yeah. >> Yeah. Anyway, that's really awkward and fun to talk about. So I wanted to share my my my terrible abstraction story, but >> all good. >> Yeah. Well, Derek, I I really appreciate the time. Thank you so much. Um I guess before before signing off here, if folks want to reach out to you, where's the best spot? Obviously YouTube uh is where you got most of your content, but uh where can people find you? >> Yeah, just on YouTube. Everything monikered as code opinion. So codepinion.com or my blog or on X. That's pretty much it. Or LinkedIn, I guess. >> Awesome. Okay. Well, Derek, thanks again. This is uh super like I really enjoyed this because uh I you know read and watch a lot of your material. I really look up to the stuff that you're putting out there. So thanks again. >> Yeah. Thanks.