Eric Normand on Code with Jason

I had the great pleasure of speaking with Jason Swett on the Code with Jason podcast. I was overcaffeinated and excited, and I went on too many tangents. But Jason reined me in. We talk about consulting, mostly! I hope you enjoy.

235 - Eric Normand

Transcript

To your listener. If you like this podcast, I want to tell you about something else you might enjoy as well. Every week I host an online meetup. In each meeting I give a presentation on some programming topic, or I bring a guest to the group for a discussion, or I do a code review on a members code base, or I do some kind of consultation with one of our members. Coming to this meetup is kind of like listening to this podcast except it's live and interactive, which means you get a chance to ask questions and participate in a conversation with other programmers like yourself. The meetup is also a fun place to meet some new friends. To learn more and to sign up, visit codewithjason.com/meetup, now on to the episode. Hey today I'm here with Eric Normand, Eric, welcome to the show. Hello Jason, thanks for having me. This is great. Yeah, thanks for being here. You and I have known each other for many years. I think we first met maybe at Microconf. I don't know what year of Microconf. But it could have been, I don't know, like, eight or almost ten years ago or something like that. Yeah, probably, like, I think 2016 was the first time I went to Microconf, so it couldn't have been before that. We also did a mastermind together. Oh yeah. So we had, I know that was so long ago too, I forget about it. But yeah, because we were both doing, like, screen casting, a screen casting mine with a couple of people. I think Aaron Francis was on it, and Derek, I can't remember his last name. Yeah, I don't remember either. Man, I totally forgot about that. But do you listen to her if you're not familiar with the concept of a mastermind? It's basically like people get together who are all on the same journey and they try to help each other advance and stuff like that. Yeah, giving advice and keeping each other accountable and stuff like that. Yeah, so Eric, you and I have both been involved in entrepreneurial endeavors over the years. People listening to this podcast are probably kind of familiar with my goings-on. I wrote an e-book and that's still up for sale and still selling copies and stuff like that. And I have kind of a whole ecosystem of content and stuff like that. Yeah. Kind of the original purpose of all that was to feed into the e-book sales. But then at one point, I kind of transitioned into feeding it into consulting. And so now everything I do, it used to be like, how can I have this stuff help my book sales? And now it's how can I have this stuff help my consulting? Anyway, that's kind of the entrepreneurial activities that I have going on right now. But for anybody who's not familiar with you, Eric, can you share what you've done over the years? Yeah. Yeah. So I'm best known in the closure community. I have four courses, video courses about closure. So I have like a beginner, an advanced web front end and a web back end. That is my main product that I sell. But I also have a bunch of content that doesn't directly sell anything. I have a newsletter, I have a podcast that I sometimes will post on. And I have a book that's published by Manning and I'm working on another book and I have a blog. So I have a bunch of stuff. I've also done a number of conference talks. And just yesterday, I was talking to someone about how to get paid to do conference talks. So I think I want to start that as well. Just as like, you know, if I'm going to do the talk, might as well get paid for it. And I think it's going to open up some interesting things. Yeah. Okay. So I want to frame the conversation a little bit so people know where we're going. You know, you and I had a telephone conversation the other day, which I feel like it's kind of rare these days, but we talked a lot about two things, domain modeling and consulting, which are obviously like fairly different things. But we also talked about like the viability of helping people with domain modeling as a consulting service, which is something that I currently do. It's not the only service that I provide, but it's definitely a part of it. Yeah. So I just wanted to frame that. Sure. Okay. Continue. Yeah. Yeah. Yeah. Because I could ramble on in random directions. So thanks for framing it. Yeah. I'm curious to know from you as someone who's done it before about how you go about selling the domain modeling, because I know you like to, I know you're at least a fan of value based pricing and domain modeling to me also it falls under the software design umbrella. And all the conversations I've had with companies about consulting and like what services they're interested in, they don't seem to be able to value software design at all. You know, it's too vague. It's too like you can't put a dollar amount on it. Like, oh, this is going to save your developers six hours a week. If we clean up this module like this, it's very hard to pin it on. And it's also put in this other bucket of waste of time, like the developers often they're already complaining about the cleanliness or the mess that they've got in their code. And whenever they've been given time, like, you know, they get a sprint to clean stuff up, it doesn't seem to go anywhere. It doesn't seem to make anything better. And so there's just this skepticism from the people who control the checkbook about what, you know, what the value is of software design. Yeah. So I just came up with this analogy just now while you were talking. Okay. Let's say you wrote a book on how to get in shape physically. And you had two choices of where to try to sell it. One is you could go to KFC and, you know, see the fat people eating their KFC. The ones who need it. Yeah. Yeah. Or you could go to the gym and try to sell it to the people at the gym who are already in shape, but which audience do you think would be more receptive and buy more of your book? To the ones who are already in shape. Yeah. Yeah. And that's kind of what I've realized. So like metaphorically, I'm now going after the people who are already fit rather than trying to find the out of shape people and helping them get more fit. That's really fascinating way to look at it. So you're going after companies who are already maybe blogging about software design and, and, you know, being open about like their, I don't know, they already value software design. Is that? Yeah. So a couple things you mentioned were like tactical and I'm, I'm not sure about any particular tactics, but that's at least the idea is to find the people who are really smart and already doing well and help them get even better. I see. Rather than trying to help the people who are performing weekly get less weak. Right. That makes a lot of sense. And I hadn't thought of it that way because, you know, you see the people like KFC and you're like, they need this the most like they're, they're, the value they would get from this is so much higher because the people who are already working out like they already probably are doing most of what you're going to tell them to do anyway, right? And so it's, it's counterintuitive to me, but at the same time it makes sense that that person who's already bought in to the value of it, that increment that they will get, which is much smaller, right? But they will value it more. No, no, no, no, I mean, they'll value it more, but the, the increments not smaller. Not only are the, are the people who are already doing well, gonna, gonna be able to use your advice better, but they have a greater capacity for improvement. So this is where the analogy breaks down because it's like, if, if you lose weight to the point you're fat free, then like you can't really optimize that anymore. Right. But with a software organization, like there's kind of no ceiling to how good you can get. Oh, that's true. And I'll also say this, there's, you can go to a gym and find people who have basically perfect bodies. Good luck finding a software organization that's already perfect. Perfect. Yeah. Yeah. Yeah, like nobody's even close. Sure. Right. Right, right. No, I get it, but they're at the gym. They're trying, right? They're doing what they can. Yeah. That makes sense. Okay. So how do you find these people or these companies? I don't have all the answers to that. Is it like inbound or you like broadcasting the importance of software design and domain modeling and so then they come find you because they're like, we love what you're saying. We already value it. We'd love to pay you money. Yeah. I think that's part of it. That kind of scenario has played out for me. Okay. So I want to zoom out and give a little bit of context real quick, a lot of, okay. So the vast, vast majority of freelance programmers are basically just employees. They do hourly coding, staff augmentation, they work like 40 hours a week for a single client or maybe 25, 30 hours, whatever it is, but it looks like a job and it feels like a job. The paychecks are similar to a job and it's like, all right. So you're a freelancer technically, but like this isn't better. Right. Um, and I like, that's something that I only discovered over the course of years. And when I finally like figured that out and lived with it for a while, I'm like, all right, this like dream I was seeking kind of doesn't exist. So that that's when I like kind of gave up and went back to a job. But then I, I decided to take another go at it now that I'm more experienced and hopefully smarter. And this time it's going better, um, you know, nothing, hmm, not to get too philosophical, but you know that, that philosopher, uh, here at Clitus, he was like nothing, nothing is things are only becoming, um, and it's like you're freelancing consulting situation. It's not like, at least for me, it's not like I have a specific way of working or being or whatever. And it's like, this is it forever. It's like, yeah, I always have a certain situation going on and it might vary wildly from year to, from year to year or even month to month, right, um, so, but, but the point I want to get across is I've been making very good money and having a better lifestyle too. And it's like, you're going to want to have at least one of the two, otherwise, what's the point? And ideally you have both. And lately I have had both. And that's not to say that like it's guaranteed to continue in this manner, um, but it's, it's been working. Um, okay, that's not the thing I meant to say. The thing I meant to say is when you start working as a freelance programmer, I think the main thing you should understand is that the most important part of all of it is sales and marketing. Uh huh. I think you should think of yourself as a sales and marketing person foremost and a service provider second, because if you can, if you can get really good at sales and marketing and, um, get good, get good clients who are a pleasure to work with and pay well and all that, all the other stuff, taxes and insurance, whatever, those are trivialities and comparison. But if you can only get low paying clients who are miserable to work with and I've certainly been there like nothing else matters because not only does your life like kind of suck in that scenario, but you like don't have enough time or money to make it better. Right. So again, sales and marketing is the whole thing. Last note on that, um, I think the like root of the sales and marketing thing is deciding what service you offer. Right. And so this is, this is where, um, I've been trying to, I've been trying to craft that. And one thing I've been doing, uh, you know, I guess I did it for about three weeks, really almost full time was just talk to people who have done consulting and it helped a lot. It helped like kind of put a lot of, give me an idea of the reality of the situation. But at the same time I wound up stopping partly because it felt like what I wanted to do was not going to be possible. Oh, okay. Yeah. Most people were, well, most people that I talked to were just like you said, they were just staff augmentation and they appreciated the flexibility, you know, they appreciated saying, Oh, this is just a three month or a six month engagement. I'll go to something else if I don't like it or they could say like only work half time or something like that. There was another group of people who were, uh, sort of, they had actually contracted people and they're like, yeah, that's actually what we want. We want someone who, um, we want someone who just comes in, they can do the job, but it's kind of easy to just disengage like cause an employee is hard to hire and stuff. They want, you know, they want someone to just hit the ground running and they can put them in this box of like here's some Jira tickets. Go do it. Um, and then there was this third group who kind of, I would call it like a hybrid. They were like, yeah, we sell it as staff augmentation. But the first thing we do is we come in and we become more like a staff engineer, right? Because, um, I mean, he was saying like the practicalities of it is they, they hire you as a, as a contractor, but like it takes them two weeks. If it's a big company to get you a computer to work on and to get you, you know, accounts and all the systems they use. So you use those two weeks to walk around, see what's going on, have like whiteboard discussions about the architecture and you're already providing value, right? You're already, um, doing the like high level architecture, engineering stuff and not just doing Jira tickets as a low level person. And so it was kind of this hybrid where you use the staff log understanding, which is what the companies like the box that they're putting you into, but you're doing the higher level stuff that you want to, which would include software design and architecture and stuff like that. So those are the three, I didn't find anyone who was like, yes, I, I just consult with advice, right? Um, which, um, which is what I want to do, right? And so people are even like, if you want to do advice, do not code because you will get put into that engineer box and like no executive, no manager will want to talk to you except, um, you know, about code. They don't want advice about like how, how the business should operate or anything like that. So that, that was my experience. So my, my original idea was to do consulting on, uh, like the intersection of, what did I, how did I phrase it? Cause this is, I changed it so many times, but my original one was the intersection of business strategy, uh, software design and architecture or something. From my business strategy, I meant, this is the thing that people, it got me in trouble putting business strategy in there because people are like, Oh, an executive does not want to talk to an engineer about business strategy, right? It's like, yeah, but it's the intersection. It's like where technology like how, how, I'm going to help you think through the technology problems, right? Yeah. Yeah. I get that. Um, okay. Um, I want to, I want to go back to something you said a second ago. Yeah. Um, you were describing these various kinds of, um, I don't know, work arrangements or whatever you might call styles of working, staff fog, um, stuff like that. Um, and I want to, okay, so much of like successor failure in, in this kind of work is, is a function of mindset related stuff. So I apologize if it seems like I keep going like super high level, but I think it's really important. Yeah. Yeah. Um, most of the like free, I'm, I'm getting tired of saying like freelancers or consultants. I'm just going to say freelancer, um, most of the freelancers I've seen have failed to thrive because they lack a few certain things. They lack, um, imagination, um, industry and optimism. Okay. So let me, let me explain a couple of those. Um, so the imagination and optimism, things are, are kind of connected. Um, and I don't mean optimism in the normal sense of the word. Like everybody knows what optimism and pessimism mean, but I read these couple books by David Deutsch recently and he defined, he gave a different definition of optimism and pessimism, which I find really useful. Um, optimism is not really like a prediction that things are going to go well in this definition. It's like a belief that things can get better. Okay. Yeah. So like I'm making this up a little bit, but he used kind of an environmental example where like we have this climate change problem, um, pessimists think that what we need is to stop using as much electricity revert to an agrarian lifestyle. Yeah. Sure. Yeah. Go, go in reverse. Uh huh. Whereas optimists might think, okay, instead of using electricity, less electricity, let's figure out how we can, uh, produce the electricity we need without the emissions that are causing so much harm and stuff like that. Right. Um, let's, let's make things better instead of worse. And so with my work, I, I am very optimistic, not in the sense that I'm predicting that I'm going to be successful, although that too, but in the sense that I have a belief that the ceiling is very high for what's possible. Mm hmm. Um, and you know, just because nobody I know has done a certain thing before doesn't mean that it's not possible. All it means is that I don't know anybody who's done it. And so with this advisory stuff, um, I'm a big follower of Allen Weiss, who's not a technical consultant. He does more, um, uh, I don't know what you call it. Management consulting? Sure. Yeah. Um, and he wrote a book called million dollar consulting because he makes over a million dollars a year consulting. Right. And I think he kind of read that and I thought it was really great. Um, I did wish that he would give more examples of the kind of work he did. Right. I was always like, okay, but what do you do? Like you're saying, oh, you got to sell them something that they want. Yeah. Okay. But give me an example please. Like I don't understand like the, the details, I get the mindset idea, but like what do you say to this person to get them to, to trust that you're going to be able to do that? And like, what is it that you do? Cause he talked, you know, he talks about results a little bit like, you know, saving, you know, saving on, uh, or like doubling someone's sales or something, right? Like he talks about stuff like that. But yeah, he doesn't give you enough examples, but still a great book. Yeah. Yeah. Yeah. I definitely found that, that same lack myself and it took me 10 years between the first time I read that book and when I was able to implement the advice. Okay. Yeah. Um, and, and we can get back to there connecting the, like what's the actual service? But, but before that, um, you had mentioned the, the principal or whatever that a contractor is easy to like engage and disengage. Mm hmm. Um, and to me, that touches on the question of like, what is the purpose of a consultant? Is it to solve a specific problem or is it something else? Um, and I think a lot of people focus on solving a problem and it's kind of transactional. Right. Um, like let's say you're an expert in, uh, databases, um, you might go and, and clean up some of these database issues, and then the issues are gone or something, optimize them. Yeah. And now since you've fixed the problem, they don't need you anymore and you go on to the next project and it's kind of project to project. But the problem with that is you always have to be finding new clients and it's not great for the client either because like maybe you're a really smart, valuable person and you could be potentially used in a lot of different ways, but they only got to use you for that one thing. And that's like inefficient because they spent all this, um, there's all this expense in finding you and hiring you and engaging you and all that stuff. And then they never see you again. So I asked myself the question, how can I provide a service such that people will want to engage me indefinitely? And this goes back to like the, the first part of the marketing thing is deciding what service you, you provide because I think it's kind of backwards. If you're like, I want to provide this service. How do I market it? No, it's like, how do I come up with a good service that will, um, that will be a good business and that's a viable to market and stuff like that. Um, I'll pause there, but that was, that was one of the big decisions I made is to try to come up with a service that could be provided, that could provide indefinite value. Right. Okay. That makes a lot of sense. Right. Cause the, the typical advice of the, the more transactional one is like while you're there, so like you get engaged to optimize their database, but while you're there, you also see, oh, their deployment pipeline really is slow or flaky. And so you come up with a new proposal, like you network and talk to the people involved and like you convince them that you can do it. You figure out how much it would save them in time and effort and strain. And then you come up with a proposal for them. And so then that's like, after we're done with the database, we'll jump into your deployment pipeline. Right. Um, and so that's how you continue the engagement, but it's like a new transaction while, you know, while you're there. Yeah. And I don't necessarily think there's anything wrong with that. And that definitely seems viable. And that's something that I'm always like keeping my eye out for too. Yeah. Um, so I don't think that's like mutually exclusive with, with my way of thinking about stuff. I guess, um, the danger is just in only thinking about, uh, transactional projects. Right. Right. No, but I like, I like your idea too, that indefinitely. So, so did you, did you come up with something? Um, that's indefinite. Yeah. Yeah. So I'll tell you the first iteration of what I came up with. Okay. That's the pitch for the first service I came up with. Um, I am now offering consulting. That was all. That's the entire pitch. Yeah. Um, and believe it or not, people think that you mean freelancing? Well, I think I included it. So the way that I did that was I sent an email to my email list of like 2,600 people or whatever at the time. And I just said, Hey, I'm offering consulting services now. Um, I probably said something like this is, I mean advisory work as opposed to hands-on implementation, but it was only like one or two sentences and then I had a link to an application form and two people did end up hiring me based on that. And both of them were people who had been following me for years. And so like they've heard me on a million podcasts, they've seen my YouTube videos. It wasn't like, I didn't have to sell them very much because they were like already sold on me. Yeah. And so to get sold on hiring me was like not big leap at all. Right. And did you charge hourly? No, I charged a monthly fee. Monthly. Okay. Yeah. And was it, was this like, did you have some kind of initial call to like figure out what they needed? Yeah. Yeah, kind of my process was like they would fill out the application, then I would give them a call on the phone and we would talk and I would just kind of ask them what their deal is, what's your situation and what do you want help with, that kind of stuff. Yeah. And then I'd tell them about like the format and pricing and stuff like that and ask them if they wanted to move forward. And of the people who applied, I don't know, I've gotten maybe 10 or 15 applications in the last year and a half since I started offering that service. Almost everybody has ended up becoming a client. But again, like most of the people who apply by the time they apply, they've already been familiar with me for years. Right. Right. Okay. So it's basically inbound kind of, I do think that people often need to be invited to engage you. Okay. Like most of those applications I got weren't just out of the blue, but I prompted them. I like sent out an email saying like, Hey, just a reminder, I'm offering consulting services. There's a link to the application. Cool. And so what kind of like, what is, what is the service? You said it's advisory or by the month, like, yeah, yeah. So early on it was, um, the way I framed it was like, you pay a monthly fee, we meet four times a month for an hour. And that's what it is. And obviously like, that's kind of hourly billing because it's a monthly fee for four hours. You can divide the number by four and there's the hourly rate. Right. And I think it's kind of like a continuum from hourly to value based, not a binary thing. Yeah. For sure. Yeah. Um, so that worked out well, and so you just have this call and they just come with questions. Is that it? That's kind of different people approach it differently. When people come with specific questions already prepared and it's very like formal and we go down the list, other people, we get on the call and it's like, so what do you want to look at this week? And they're like, I don't know, I'm like, all right, well, what are you working on right now? And then we just kind of get into it. And sometimes it's like a, a pair of programming type thing, but it's always their hands on the keyboard. Not me. Got it. Got it. Okay. Okay. Do you don't have to do any prep? No. And people have asked me like, hey, do you want me to send you my code? Do you want me to give you a GitHub access? I'm like, no, please don't because like I want it to be very, a very sharp line between where we're talking and we're engaged right now and we're off. I'm not going to do any homework. Right. So you considered selling the more like retainer where like you could be available for questions all the time? Yeah. In fact, I did put that on a proposal recently. They didn't take me up on it, but one of my, one of my proposal options was 24/7 access for one specific individual, which is something that Alan Weiss does. I think I read in one of his books that he would charge like 10 grand a month just for the privilege of being able to call them anytime. Yeah. Yeah. So I put that on the proposal and not that specific number, but I put that service on there, but they didn't take me up in this case. Yeah. Yeah. Okay. Yeah. I mean, it sounds like I need to come up with something that like that because I started doing an office hours, just free call, I just say, like, join the Zoom at this time on Thursday and I'll be there and I'll answer any questions you have. Because I wanted to show people like that, you know, there's a variety of things that I could help you with. Yeah. And so, you know, don't think, oh, you're the closure guy, you're only going to talk about closure. Like, no, I've helped people with their business questions. Actually one guy was getting into consulting and so I told him what I knew. And sometimes it's a closure question and sometimes it's like more general stuff. And that's cool because I live stream it so like you can watch it. And the idea, my idea was like, just show people that like, what it might be like, you know, to have a call with me. So I know I said that nobody was doing a more like advisory consulting. There is one person, but he's not a programmer. So I kind of forgot about him. He has a cool model because he wants to advise startups. And so he's very hooked into like different startup communities around the world. And his model is if he likes you, he likes your product and the, you know, the founder, he will say we will have a weekly call. I just want to be involved, you know, it's free, weekly one hour and it's like set on the calendar so that there's no overhead for like scheduling every week. And he's also like, I'm kind of strict if they don't show up a couple times, it's over. Like I just don't, I just canceled the whole thing. And he'll talk about anything. But then if it's something seems like, hey, this problem that you're dealing with is kind of involved, we probably need two or three hours a week to work on this. Then he charges them, right? And he gives them, you know, some fee based on that. And he's like, I can only do that though with a couple of companies at a time, right? Because once, you know, once your head gets filled with like four different startups, you're like, wait, where were we again? What is your product, right? So he has to, he's like, I just do like one day, I have two days, like marked out one day per startup and I get two of those that I can sell and I can't remember his rate. But it was something like $6,000 a month for that one day a week. And so if he had two is $12,000 a month, which I think is fine for him. And then he has this other day that's like all the one hours that he's still working on. I thought that was an interesting model. I wonder though, like startups often don't have that kind of money. That's what people say, you know, as a startup, you're limited in funds. But yeah, startups are very, they're very diverse, you know, right. And some startups have a small amount of money. Some of them have hundreds of millions of dollars, right. And some non startups have hardly any money. Some non startups have a whole bunch of money. So I don't think startup or not startup, I don't think that's really a. That's not the issue. Yeah. Okay. Yeah. And for me, so you had asked like what's my service? It's evolved a few times, but where I'm at now, and this is the one I've kept the longest, I think is I'm a technical advisor to startup founders. Okay. So you are going after the startup? Yeah. Specifically, because people have to know like, is this for me or not for me, like who is this for? Am I in that group, that kind of stuff? So it's a bit, it's a bit of an arbitrary choice on my part. But I think it makes sense. Because a lot of startups go through this kind of inflection period where they're doing things kind of, I don't mean this in a derogatory way, but they're doing things kind of sloppily because they can afford to because things aren't that heavy yet. Right. But then they hit that inflection point and things heat up and they can't afford to be as sloppy anymore. And they might not really fully know how to get more mature to meet the new level of seriousness of everything, or they might kind of know how, but they're busy and they have a whole team and stuff like that. Sure. Yeah, so that's my pitch now. Okay. And so where does the domain modeling come into that? Yeah. So if you go deeper into my pitch, there's three specific areas, automated testing, domain modeling and object-oriented programming. Okay. And by the way, since I've come up with this pitch, I've gotten three new clients because I came up with the pitch a few months ago. I've gotten three new clients since then. The pitch never came into the picture. Huh. Okay. Yeah. So like... Maybe it was a useful exercise for you, but like... Yeah. You know, it's kind of like, you know, the more experience I get, the less any job interviewer has been interested in my resume, maybe it's that kind of thing. They're like, "How much postgres have you actually done to come on? Like, I've done every day to waste by this point." Right. Yeah. Sorry. You had asked me a question right for you. Yeah. No, about domain modeling. Oh, yeah. Yeah. The technical advising. Oh, man. Okay. So most of the people, I don't know, I've had maybe like eight or ten advisory clients at this point, most of them who have engaged me did so mostly for like testing and OOP and like very technical stuff. And I found in every single case that their bigger problem is that they have a muddy domain model. Sure. Yeah. I mean, that's every piece of software, right? Yeah. Exactly. Yeah. And then, you know, I, first of all, I like state that fact to them. I'm like, clean code is downstream of clear thinking. Yeah. A lot of people like to talk about short methods and small classes and stuff like that. And that's all great. Yeah. But like, you can pass every linter you have, but your code could be completely nonsensical because the domain concepts you, you conceived of that your code describes don't make any sense. Right. And share that fact with them and then help them understand what that means and how they can start to clean that up. Can I, can I, I'm just, I just want to like put a bookmark here because you're speaking my language and I feel like I'm writing a book on domain modeling, but this is the kind of thing that I don't think is that widely known in the industry that like, I've just had a lot of trouble finding people saying this that I have, I have this whole like rant about how software design talks so much about the code and its quality and, you know, it's too complex and nested if statements, long methods, too many classes, you know, whatever it is, it's all about the code. But they're leaving out the other half, which is like what the code is supposed to be about, right? Like, does it actually model what the problem is? And I, I feel like even in some of the like better presenters and authors on software design, they're leaving that what I consider like maybe the more important half out of the picture, even though it's there. So like I was just reading Sandy Metz's book, like she's a great software designer. Like I love her material. But when I'm reading it, I'm like, there's domain modeling right here, but you're just not talking about it. Like you're using refactoring and you're saying it's all about refactoring, refactoring is so important, but then what are you refactoring to? You're refactoring to a better domain model. And she hints at it with like vague terms that if you're not paying attention, like you could just kind of glance over. And I feel like that half of the material in the whole industry, I'm not just picking on Sandy Metz. That was just an example of like a really high level person who, who is missing it. Like that's what my book is trying to be, is trying to like expand the vocabulary and understanding of like what domain modeling can be. So anyway, I'm finding a kindred voice here because that what you're saying, like people not understanding it, that they're like, they're following what everyone's saying to do. And you know, the good advice, like long methods are better if you can, if you can get away with it. I agree with that. Where do you mean short methods? I'm sorry. Short methods are better if you can say the same thing in shorter, right? And all those like rules of thumb, but they're missing the more important thing, which is like, like maybe that class doesn't really, like the reason their code is messy in the first place is because they've got all these workarounds because the concept that the class represents is just kind of like you were saying muddy, like it's just not what it should be. And I remember on a previous podcast of yours, you were talking about working at a job where there was this concept of the facts, right? There's like a facts class. Oh, right. And you were like, well, it's not like when you think about it, there's no such thing as a fax. We might talk about it in like casual terms that like, oh, I got a fax today, right? So it's a fax. And we have this tendency in object-oriented programming to say, oh, it's a noun. Take it in object, right? Make it a class. But fax is really an action, right? You can take a document and you fax it to someone. And then on the other end of the fax machine, it's another document, right? It's a copy of the document. It's not a fax, right? And so just getting clear on those ideas and how they actually work and not the kind of casual way that we think about it. I mean, that is so empowering and it cleans up your code better than like, oh, this method is too long. Let's make it shorter, right? Right. Yeah. I agree so much. Yeah. So it took me, you know, to be fair, I think a lot of these things are like super not obvious and they took me a really long time to realize. It took me like 20 years to realize that, um, well, okay, I was talking with my friend Joel the other day on this podcast. And we talked about the fact that like as software engineers, you can say we write programs and we write them in code, but like it's maybe more precise to say that we build systems. Yeah. And a software system is like technically it's made out of code, but like not really, it's actually made out of ideas. And I think that's a big shift. It's like kind of a subtle thing, but like it's a super huge mindset shift, I think, right? The code is just an encoding of those ideas into something that can run on a computer, right? Exactly. So we're talking about domain modeling, um, where is the domain model? It's like, I don't think, yeah, yeah, yeah. It's like the domain model is kind of in the code, but like the code is an artifact. Like the domain model also exists in your mind, right? And that's like, yeah. And that's also, I think when it may be one of the better, I don't like the term technical debt, but that's one of the better terms or the better, better definitions of technical debt that like, you know, you have like, this is how it should work. Like a fax shouldn't be a thing. But in my code, it is a thing. And I have this difference and I don't have time to work on it now. So it's just debt, right? Yeah. And that, and so that to me is like the, the most, I still don't like the term. I think it's. Like, may I, may I dazzle you with my genius for a moment? Sure. Um, so I, I have an alternate analogy, it's probably not original, but instead of technical debt, I have an analogy of like dull blades. And I think it, I think it maps with, I think it maps better onto everything. Yeah. So like, if you have this like crappy class that's hard to work with, that's a dull blade. And like, if you want to refactor it, clean it up before you work on it, you sharpen that blade so that you can cut more efficiently with it. Right. And like you might be, that's a great metaphor because it also says like, you know, if you're just chopping like two slices, maybe it's not worth sharpening it. But if you're going to cut a whole meal of vegetables, like sharpen it, it'll like save you half the time, just a few minutes of, you know, honing the blade. Now you can chop the whole vegetables and half the time, right? Exactly. And the other part of it that I think is significant is blades get dull with use, no matter what. Like with debt, you can just not use the credit card and you don't have any debt, no problem. But like in programming, like the blades are going to get dull, no matter what. Yeah. Yeah. No, the other problem with debt, especially from a business perspective, because that metaphor was designed to help communicate with business about, you know, making trade offs and stuff. But the problem with debt from a business perspective is debt is not a bad thing. Right. Like and debt, as long as your revenue is increasing faster than your debt load, you're actually doing okay, right? And so a business person is like, oh, yeah, we know we've got debt, but we're just adding more engineers, more capacity, because where our revenue is growing, we can pay them. And so there's no problem. The issue is that technical debt or just, you know, problems in the code, let's call them, and especially complexity, there's a ceiling where your brain can't hold it anymore. Right. And so it's not, you can't just increase with revenue, like no matter, like you can't just add programmers to get more brain power, like each brain has to be able to hold it. And we only have a certain capacity. Yeah. So there's this line that once it crosses, it's like you're, that's, you're just slamming on the brakes where you can't make progress anymore, because you can't keep it in your head anymore. Right. Exactly. Yeah. And like back to the blade thing, it's like eventually all your important blades get so dull that you can't cut anything you need to cut. And there's only one way out of it, which is to sharpen the blades. You can't just like take on more debt to pay for the other debt or something like that. Right. So yeah, that metaphor is kind of unfortunate because not only does it not fit perfectly, but I think it encourages unhealthy behavior. Yeah. Yeah. Yeah. Yeah. I like the blades. I'm going to start using that. Please do. I would love, I would love for the technical debt metaphor to die and the blades want to totally replace it. Yeah. Yeah. Yeah. I'm sure it has its own problems, but it's probably better. No, Eric. It's perfect. Yeah. So, so I stopped you. I started commenting on domain modeling because I liked what you were saying about it. So what you were saying was you get hired kind of for software design, cleaning up the code and then you're there and you're like, but actually your domain model sucks. And that's, and so then you have to kind of educate them on that. Yeah. And so, yeah, go ahead. Yeah. And it becomes kind of a, I've explained what I do to people and several people have been like, oh, so you're kind of like a therapist and I'm like, yeah, exactly. Because like, I don't know, a couple of clients we've talked because they've been like founders of bootstrap software companies and startups and stuff like that. And we'll come across these muddy domain concepts and we'll keep going like up the pyramid. It's like, okay, this really like fine detail is misnamed. What's this like bigger thing it belongs to? Oh, that's kind of muddy too. Like what's this bigger? And eventually we just get to the very top and I'll ask the person like, what is your product? What is your business? And what's really interesting is, I don't know, I remember at least one client and I'm like, what is your product? And he's like, um, good question. Like he didn't have an articulation of what his product was. Right. What problem it was solving. Yeah. And that's not to say there wasn't an answer because there was, but that's something that I think is really valuable to just have like, to, to be able to say it cold. Like what's your product, you know, you should be able to answer that question. And then it's cool that you got all the way to the like the business level, right? Like I have this hypothesis really that good domain modeling can actually clarify a business. Right. And you're kind of showing that as, you know, anecdotally, but like that it is possible. Like I've had experiences in companies where coming up with a better domain model actually informs the business and provides new opportunities for the business to, to something new to sell or a competitive advantage or something interesting. And so it's, it's all anecdotal. And I think it requires a lot of skills. So you can't just say, yeah, like do domain modeling and you can, you know, your business will be better. But I think that it's something I've done before. And so I know I could do it for other companies. And so that's the kind of thing I would like to sell. So I'm very, very interested that you're, you're able to do. Yeah. And I think domain modeling is downstream of good product design. This is something that's another thing that took me a long time to realize I worked on a project where the UI was nuts. It was just crazy. Yeah. And so the code by necessity was crazy too. Sure. And I, I like campaign to like rethink the UI a little bit to try to make it make more sense. But also the code could be better and you know, it's good for the product to make sense. I wasn't successful in that case. But like, I think that's helpful for people to realize like it's downstream of the product design. So you need to like, if you want the code to be in good shape, you have to have good product design. Yeah. And that's something that like a lot of people don't know how to do like most UIs of most software products are just total garbage. Yeah. Yeah. Yeah. Sure. Sure. That makes me think like, so I'm, I'm, I'm trying to turn this into practical terms that I can use. And one thing I noticed and tell me if this isn't a contradiction, but it seems like a contradiction. Like you're giving all these examples of like, yeah, and then they didn't have a clue about their business or they couldn't at least articulate it right away, which a good, a good founder should be able to do. Or you're working at a company and they have a crap UI. But then at the beginning, you said you're looking for the clients that are already, already fit, right? Yeah. At least at the gym. Sorry. They're at the gym. So I wonder if that a contradiction or is it just kind of like what you said before that like, even if they're at the gym, they're probably still like, like, well, it is a contradiction. And also it's not. So for one, I didn't start off with that approach. It took me a while to realize that that's the approach I should take. Yeah. And then just because I seek those kinds of people and organizations doesn't mean that that's exactly who I find and end up working with and stuff like that. Right. And you can't always tell from the outside. You can only. Right. Yeah. Okay. Yeah, yeah. Yeah, because I'm trying from impractical terms, I'm like, do I go to the companies that have good software design, you know, like, is that a good way to, you know, a first pass filter to like, you know, find a niche of people to contact? Is that the best place to start? Because if they have good product design and like another thing I look for in companies that I would like consider being an employee for is that they have a theory of the product. So like, just a silly example, but it comes to mind, I was listening to a podcast and I think it was the, the CEO of Asana, right. And so Asana is like this product, project management tool, like tasks, tasks that you have to do and stuff like that. And what the CEO, it impressed me. I've never really used Asana. I used it like 15 years ago and it looks totally different now. So I don't know like what it does all, but the, the thing that impressed me was he said, we have a theory of how work gets done and how it should get done at large companies. And you know, he's like, and we have it all detailed on the, on the website. Like, you know, how things get communicated, how tasks get partitioned out to people. We have a theory and I was like, yes, like I use JIRA and I don't think they have a theory, you know, like there's all these project management tools that just seem to be like, well, our theory is you write stuff down and then you do it, you know, and there's like, there's no real overarching theory. So all this is to say like, that's a signal to me that if they have a new idea about how things should be done, not just like, oh, we're just putting features that customers want, you know, like they have some vision for what it, what it should be. So that would be another thing I would look for. Yeah, yeah, yes, that resonates with me so much. Yeah, like, this example is kind of trite because everybody always uses it, but Apple, like Steve Jobs had a theory, I think it's safe to say, if I'm, you know, understanding what you're saying. Yeah, yeah. Sure, he did. You know, or something like 37 signals, you know, yeah, and talk about their products. Like, this is what it's about, and this is why we're doing it this way. And, you know, they talk a lot about simplicity and stuff, but I think they also have an idea of like, like, for instance, for Hey, the email service, they're like, no, the main idea is like, that you should be in control of your inbox, right? And like, to me, that's like, okay, that's a, that's a big idea that that, you know, maybe it's wrong, you know, I'm not saying that. But like, it is an idea that you can build an email service around. Yeah. Yeah, I think something Apple and 37 signals both really have is focus, which is something that a lot of focus and discipline, which is something that a lot of organizations lack. Yeah. Yeah. Right. I remember, I was interviewing for Jobs a few years ago, and because I do closure, there's a company called Clubhouse that does like project management. And I know someone who works there. So I was on the phone, like, you know, what is the company like and stuff like that. And I asked like, so what is the idea behind Clubhouse, like, what is the theory of project management that you have? And he's like, no, it's just, you know, standard tickets with Kanban boards and there's no theory. It's just they're trying to do like a better job than Jira, right? And it's like, okay, like, that's kind of a disappointment. Yeah. I mean, I understand that it's like a useful product and people like it and stuff like that. But like, it, it also is not the kind of company I would want to work for, right? Yeah, exactly. Um, and the other big issue that I see a lot is people are like afraid to step up and take a stand and tell people how to do things and stuff like that and be like the chef in the kitchen. Yeah. Like as a consultant, you mean? Oh, sorry. No. I mean, as like a, as like a leader inside an organization leaders are afraid to tell people how to do stuff. I see. Yeah, they seem to believe that they, that the way you get things done is to like hire a bunch of developers and then tell them to have at it, which is like, dead never works very well. No. No. And people want direction. Yeah. Like they do want autonomy, but like they need to know, I mean, the companies I've worked at where I'm like, what do I do? Right? Like, I mean, if it's a, okay, if it's a startup and you're getting equity, like, you know, it might be a little different where it's kind of like, we don't have enough time to manage you and just pick something up that you see is wrong and just work on it. You know, I've definitely been at companies like that. But at the same time, I've, those same companies, I've noticed a lack of that kind of leadership where, you know, it's the focus and the discipline of like, this is the vision that we're working on, anything else, just don't work on it. And the leader kind of just has to keep reminding you, right? Just keep reminding the team like, this is what we're working on. Does that task that you're working on? Is that part of that? No. Okay. Drop it. Like just delete the branch, start working on one of these tasks that is under it. And I don't know. I appreciate that so much. Yeah. Yeah. And it's even worse now that everybody's remote, it's so hard, like, like a team isn't going to like congeal and arrive at a direction on their own. Like I see so many at various organizations, I see so many debates on Slack about technical issues and stuff like that. Maybe they're good worthwhile debates. But like, why isn't the CTO stepping in and being like, Hey, this is how it's going to be, you know? In Postgres, let's move on. I mean, not to like, I don't mean necessarily in a way of like invalidating the debate or something like that, but being like, this has been a good debate. I see we've weighed this, this and this. My judgment is that out of A, B and C, C is the way to go. So that's what we're going to do. Thanks for bringing this up. Everybody here earlier, all the arguments and all sides and like, I'm making a decision. Yeah. Yeah, I even see it where it's, it's like, I've been at companies where we were doing everything by consensus, right? And so we had the eight people on the call deciding what database to use. Let's use that as an example. And the CTO is there too. And he wants the team to do it by consensus so much that he doesn't just push it over the line. Like everyone's like, okay, we're using Postgres, right? Like we've all talked about all the databases and we're kind of like, yeah, Postgres is the right answer. And the CTO, we're all waiting for him to be like, okay, it's Postgres, right? Like it's there. The football is like one foot from the touchdown. And he's not picking it up and like pushing it over the line, which is like his job, right? No one else has that authority to just say, okay, it's Postgres, let's move on. Right. Yeah. And that's so common. It's really heartbreaking to see. Yeah. And so like I haven't talked about that a ton with my clients because like here's another thing about the trajectory of my work so far. I started in January 2019, I was doing it alongside a full-time job in 2019. No, no, no, sorry, 2023, I was four years off somehow. January 2023. And then in November 2023, I left that job. Okay. Early on, my clients were like CTOs of super small bootstrapped software companies where like the CTO is the only programmer and a few clients of that. Then like one client is a VP of engineering who runs a team of six. But then lately, the clients have been different. Like right now, I'm doing more of like what you might call a transactional project for a startup. And I'm helping them like clean up some of their test code and refactor an area that's hard to understand. Like we were talking about dull blades. They have a dull blade that needs to do some really important cutting, but they can't cut with it. I'm helping them sharpen that blade. And then I got hired by, I guess I can say this, University of Michigan last year to help one of their teams. And then I got hired by them again this year to help their team again some more. And this is in the like once a week kind of thing, the call, weekly call. Yeah. And then in this round, I'm actually going to, because I live in Michigan too, I'm going to go over there and teach an in-person class for a couple of days. Yeah. And then the contract isn't signed yet, but I'm expecting to be working with a startup with about 30 developers helping them with their testing practices and stuff like that. So the trajectory that I hope I'm on that I seem to be on is like going from working with these really, really small bootstrapped software companies to like bigger startups with teams and stuff like that. Yeah. Yeah. And I guess I said that because I want to emphasize that these things I'm saying, it's not as though I've like preached these things to clients and then they've like changed and made an impact and stuff like that. These are things that I haven't even like tried on people yet. Sure, sure. Yeah. And it also makes me think about like the kind of trajectory I would need because I know I'm starting out, so I can't just like choose, I can't be choosy about the kinds of companies I work for. Right? Like if I want to get started, I might have to do it and like, you know, work for a company that isn't my ideal client might have to do it for less money than I would want to eventually hit. I'm wondering if you have any advice for like, how to, how to get started like that, like where, where do you, yeah, like where do you start when you know it's not where you want to get to? Hmm. That's a good question. That's a good question. Because often where you start is like against all the advice, right? Because people like, oh, don't work for free, but like maybe I got to work for free to get a couple under my belt, you know, or, you know, don't charge hourly. Well, maybe the first one I charge hourly because that's, you know, that's, they're very strict on it. And like, I like everything else about it. Like maybe I should just charge the hourly, you know, man, I got to say something so much of the advice in the like freelance programming community is such bullshit. There's like, there's this whole economy of advice dispensed by people who have never done the thing. Yeah. And it's bought by people who aren't doing the thing. And it's like this entire economy and it's all fake. Right. So like, I think a lot of that stuff is bullshit and I like, I'm not afraid to go against this advice. Like, right now I'm working hourly for one of my clients. And in a way it's a compromise, in a way it's great. Like hourly isn't bad. It just has pros and cons. Yeah. And charging, you know, value based pricing has pros and cons too. Mm hmm. And it's like sometimes the pros and cons of one thing are better than the pros and cons of the other thing. So I take all these things on a case by case basis, you know, don't work for free. I, like just recently, I offered to work for free with somebody because they don't know me. And like, I can either work with them never or I can work with them for free for a month and then maybe they like it and we'll work together on a paid basis. But how do you, how do you start, what you have your email list, right? Mm hmm. That's right. Yeah. So what I try is you could just try exactly what I did, which is like put up an application form and send an email and say, Hey, I'm offering consulting services now. It's like the default format is like we meet once a week and you pay by the month. And see if you get any bites. Yeah. Yeah, I like that, I like having the default format and like figuring out the positioning as I go because I don't know, I've just had so much conflicting advice right now and people critiquing my positioning and then I change it and then someone else is like, you know, this is a problem here, like, I'm just like, I just need to get a client. Yeah. See what it's, see what it's actually like. I'm at that point now. Yeah. Yeah. Yeah. I think you should be like really skeptical of all the advice you get and like my, my like advice, my meta advice is to like ignore most advice and trust more and you're like first principles reasoning, no, I buy that. I find that business advice is usually really bad because people don't have all the details you have and often it's of the sort of like, well, you should be doing this other thing instead. It's like, wait a second. You told me to do what I'm doing a month ago or like, you know, they're like, Oh, the real opportunity is over here and it's like, yeah, maybe there's an opportunity there, but that's like a whole other business that I would just have to focus on that and just abandon what I've got here. Yeah. And like there, I've just be jumping from one thing to another like, like the advice is like it's, or it's the people who've never run a business who are like, what you, you put out one tweet and you didn't sell out your core, like what, you know, you know, you're like, Oh, I'm still trying to sell this course. No one's buying. Did you tweet about it? You know, no, that's, you don't know how it works. Yeah. Yeah. I've totally dropped out of like all those ecosystems. Like we talked about masterminds, like I quit masterminds some years ago and I've never ever gone back because it's like the, the helpfulness is like less than zero. Yeah. I think I'll just speak for myself. Like if I go to a mastermind, I think it like gives an illusion that I'm doing something. Whereas if I, if I don't go to a mastermind, then there's a complete vacuum and the only thing that will make me feel like I'm doing something is actually doing something. So I, I find masterminds useful because a good one will focus you back on those first principles that you say, you know, like one thing I remember as the microconf experience, which isn't really a mastermind, but you know, you'll be talking to someone and you're like, Oh yeah, I'm working on this podcast to do this thing. And they're like, who's your customer again? Right. And what's the problem you're solving? You're like, Oh, damn it. That's what you're right. That's what I should be thinking about and not like not jumping to the marketing and the, and getting out there. Like I should really have a better idea of that. And similarly, I've had experiences actually in the mastermind that we were in where I was like, yeah, I've been working for the past three days on the, you know, design on my website. And they're like, or, or like I'm trying to get Facebook ads or, you know, or I'm thinking of jumping from closure to a more popular language. And they're like, you know, you, you don't have a good funnel set up, like you're going to send Facebook ads, but you don't have a funnel. Like what's the point, right? And so you should like figure out your funnel cheaply with the traffic you have. And then once you're like, Oh, I could just open this spigot. Yeah, send traffic to it. So they, they have given me good advice like that. Like, I guess, talked me off of bad decisions before I invested too much in them. Yeah, that, that sounds useful. And that sounds like good advice too. Yeah, maybe I, maybe I partly take back what I said. Maybe I just didn't always have the best experiences with me. I mean, it's really hard to find people who are actually doing stuff. Yes, that's right. They have to be working on it and trying. And yeah, no, that's true. Yeah, that's true. Okay. Well, we should probably start wrapping up here. Sure. But I'll say this, if you're up for it, you know, we got a little into into domain modeling. But I'd love to have you back one or more times to talk more about, you know, just domain modeling like the technical stuff. Cool. Yeah, that would be fun. Yeah. Well, before we go, is there anywhere where people should go to check out your stuff, hire you for consulting services, all that stuff. So my site is ericnormand.me. So that's ericnormand.me. I didn't get the dot com. Someone else got that like in the late 90s, unfortunately. And if you go there, you'll see links to all my stuff. I have a newsletter podcast. If you go to slash consulting, you can see the current positioning I've got there also slash office hours. If you want to join the office hours, I'm always happy to have more people on there asking cool questions. So awesome. We'll put that stuff in the show notes. And eric, thanks so much for coming on the show. Thank you so much. Bye.