Skill Sets for Success - Evolving from Coder to Developer

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back. We are continuing our developer journey. In this episode, we are going to talk about skill sets. This gets a little bit into everybody's favorite is like, how much do I charge for what I do? And it also talks about it's going to get us thinking a little bit about the things that we initially thought are really like our high value pieces are actually as we go on are not so much our high value pieces there. We're getting different skill sets. Before I do that, I'll introduce myself. I am Rob Broadhead. I'm one of the founders of Develop-a-Noor, also a founder of RB Consulting, where we simplify and automate your world to get you down to very simple products. We're trying something a little new. So I'm going to throw this at Michael first, and then I'll come back and give mine, which is basically we're going to let him introduce himself and then give me like a quick what's something good, like a good thing that happened today and a bad thing that happened today. Short, we can't get too far off in the weeds. So let's see how this works. Go for it. Hey, everyone. My name is Michael Moulache. I'm one of the founders of Develop-a-Noor and founder of Advision QA, where we help small to mid-sized businesses and clinicians build software solutions that help improve their business. Now, for good and bad this week, the good, I've been able to successfully get a old database system kind of articulated, backed up into a newer system. Downside, I still have some data issues I got to work out. So where it could be good, almost 100 percent, at least I'm down to one percent that's failing. That's a pretty good good and bad. So I think I'll sort of go the same way. Is good is I managed to get there's a application I've worked on for quite a while that I hadn't looked at for a while. So the bad thing is when I looked at it, it was like, oh, there was some stuff that needed some cleaning because there's some it's just it's one of those you come back six months later, you're like, what the heck was I thinking, even though it's been a couple of years, but it was quick and dirty. So the bad news, the bad thing is I looked at it like crap. I got a lot of work to do. The good news is it wasn't too hard to refactor it. There's like 18 places. Basically the same section of code was there. Turn it into one section of code, clean them all up. Boom. As I say, Bob's your uncle. You got a lot better, lot faster, lot smoother interface. So there you go. That's our that we've survived this. So we will continue on. I want to talk about in particular, this gets into a little bit into the the steps of the SDLC, the software development lifecycle, which is you require you gather requirements, you design implementation, testing, deployment, maintenance, you know, blah, blah, blah. You're going through those basically. I'm sure I missed one, but it's basically it's those six. Now, I think we because we start out our resume, our calling card is code. It's what language do you know? What have you done in it basically? And for us, a lot of us, particularly when we start out, it's just like, well, I know that I've got X years of this technology. I've been doing Java for three years and now I've been doing Java for four years. That's how we grow. But there's a point that's usually I think a lot of times it's once you get into that three to five year range and definitely once you're getting into that five to seven year range into your career and beyond, that there are other things that matter on your resume and your value, which also is how you actually charge like what your your rate is if you go out and you consult or you've got a side hustle. Now it's tempting to just say, you know, you've got this steadily increasing value that's based on you as a developer. The thing is, is that as you develop more and as you become a better developer, not a coder, that's where we're talking about being a better developer. There are skills and experiences you have where you are now able to do things, for example, extract a database and design a new structure for that or gather requirements for an app, for an application. You can also help with that. There's other things around that. Things like gathering requirements, designing a solution, estimating. You're better at estimating than you were five years ago or 10 years ago. Using that to help build better tests, to help design project plans and milestones and things like that. So you have a you're sort of going to be moving out of development. Development's always good, but it's one of those and it may be high value to some extent because you may be solving unique problems, but you also have the more we'll call it like the softer skills of design and requirements gathering, which tend to be much, much more valuable to a project, to a customer. The other thing that's in there is your we'll call them your management kinds of skills as you you probably will grow into being some sort of a lead or a mentor, but there's also some point that whether your title is manager or not, that you actually have people that you sort of direct in some way you manage in some way, form or fashion. And if you get down that path and they talk about, you know, do you have HR responsibilities like reviews and raises and stuff like that or other stuff? But the the team dynamics that you bring also will start to allow you to essentially charge a higher rate because you have maybe worked with offshore teams, worked with cross functional teams, worked with teams that are in a hazardous or negative environment. Sometimes you get in a politically charged environment where you've worked on a project that's one person's flagship and somebody else is trying to sink it. You know, there's there's these kinds of stories and skills that you bring to the table. And as you're looking at, which some of us do, and this is what got this conversation going, is some of us price ourselves. We have billing rates based more on what our function is. So if you hire us to, you know, let's just say, for example, if you hire me to write COBOL code, that's one rate. If you hire me to write Java code, that's another rate. Spoiler alert, the COBOL code is going to be an insanely high thing because I don't want to ever do that. But if you hire, for example, as a to consult or to manage or to manage a team, it's going to be a different rate if it's to design a solution as opposed to just code something that has been already highly required. You know, the requirements have been highly refined and we're ready to go. Those are different skill sets and different rates. And part of that works with it's the market rate. And part of it has to do is like where you can assign skills if not. And then it does get into situations where it's like, yeah, you could hire us to go write HTML code and do a very simple little application. But we're probably not going to want to do that at all because the rate we're going to want to charge that we need to charge at sort of our minimum is going to be way beyond what that work really entails because you can find somebody less skilled. Those are sort of my those are my opening thoughts, my parting, you know, my initial shots across the bow. So I want to throw that to you. And what are your thoughts and what have you experienced with this? So it's one of the biggest problems I've had with this particular topic. And we've discussed this for years is as we have moved up in different positions with different companies and that we, you know, we get different salaries and certain markets will pay certain things. But then as we started branching out on our own, starting to become consultants, starting to build our own businesses and go after new contracts, we typically run into a couple different areas where it's hard to say what your worth is. You know, you essentially are selling your company or your skills to someone else. So you have to kind of prove that you can do it, but also make sure it's something that they can pay, are willing to pay and is actually within the market. So for instance, you know, I can charge a rate of eighty five dollars to be a Java developer to go write code. But in some markets, that's too high. For instance, if we're trying to compete with overseas, typically we're going to have to offer a lower rate if we're going up against some offshore teams. Now if we have a low bid competition where, you know, stateside or, you know, within a smaller sector, you can charge a higher rate because your skills aren't very limited in demand and there's not going to be too much competition. The other problem you run into is, can your customer even afford that? You know, some of your smaller businesses don't have a large amount of capital, but they need the help. So then you run into a problem of, well, you have the skills and you probably have a solution that can help them. But is it worth your time and energy to do it because you're not going to be able to request the rate that you need because they just can't afford it. For instance, the co-starters I went through, there were two people that one has this great idea for an app, but she literally is still bootstrapping her business. She's getting grants and, you know, still building business. So she does not have the capital at all to even think about doing this. Now, that doesn't mean I'm not going to offer or, you know, she can't ask for guidance or things like that, you know, more than happy to help there. But I can't write the solution for it. I mean, it's just that that's not feasible. But then you have the other side of things where, you know, you run across a project that is something that you really want to do. And you're willing to take a little bit of a cut. But like you said there, there's different levels to that. So one of the problems I have always had is when do I charge more for different services within a project or within a statement of work? And I still struggle with that today. I mean, you don't always know what your I mean, you can put a price tag on what your skills are, but you need to be mindful of the market that you're in or the sector you're targeting. I agree. And there's there's a lot there. It's actually probably another episode that we'll probably go into and get a little deeper into that because there are there are there are a lot of theories and thoughts around those situations. Those are not unique to us. For example, I think one of the really one of the best easy to digest discussions around pricing comes from Tim Ferriss's Four Hour Workweek. As he talks about and I think it's where I think this is where he really got into it is where he talks about quality of customer and he talks about the kind of work and some of those kinds of things that you do. And that really has that has been more true to me than just about anything else. I have found that if I want to compete, we'll say with like, you know, a lower cost offshore team, then it's not worth it because I'm not going to be able to provide the quality that I want to at that lower price. And even when I've gone into customers and I've said, you know what? I get where they're at. I really want to do this work for them and I give them a lower, you know, a discounted rate. It ends up biting me because they get used to that. They're still wanting, you know, really, it's where you sort of get stuck because like you have certain things that you want to bring to the table and maybe you do anyways. But then they start sort of taking that for granted. And the next thing you know, you're you're being sucked into something more so than you want. One of the things I found that does work is talk to them, be very open about like, you know, budgets and stuff like that. Say, hey, this is my rate. I don't think it's going to work for you because here's your budget or here's where you're at, your bootstrapping or things like that. I've got a customer, for example, where it's just. Where it was basically there was a huge amount of stuff that we wanted to do together. And it basically came down to, OK, what can you afford on a, you know, what's your budget, monthly, weekly budget kind of thing? And then what we'll do is we'll work into that. And actually, in this one, I was just like, you know what, I'll just. We'll aim for that. We'll probably do more than that because we need to, because there's just more work that we need to do on a weekly basis to keep it alive and to keep fresh and to not sort of have to, you know, do a little bit of work and then pause and then come back and then do a little work and then pause and come back because there's all that restarting kind of effort that goes into it. Instead, it's like, tell you what, you know, your burn rate, for example, you know, I'm just picking a number. Like if your burn rate is ten dollars a week and or like easier is like ten hours a week, you can afford that. OK. But we really need to do 15 hours a week of work, then you can do like we did when we said, well, we're just going to charge you 10 hours a week and we're going to be just sort of like, you know, we're in the background, we're going to be accumulating some extra stuff. So somewhere along the way, there's going to be like we're going to take a week off or we're going to get to a certain point where we're actually done for a while. And then you're just going to keep getting bills to start, you know, working off that backlog. Now, if you do something like that, you know, beware, because it's one of those they could disappear on you, they could screw you over. There's a lot of things that could happen there where all of that stuff could just disappear. But you can work with your customers based on, you know, trust and things like that. If you walk into a situation where you don't trust them and they're trying to lowball you, I would just say walk away, because if you start out in a that kind of a contentious kind of relationship where you're really trying to get like squeeze every penny out of you and you're, you know, you're not feeling comfortable about that, you don't think you can afford to take them on as a customer, then go with your gut and walk away. Now, if it changes over time, that's different because now you've invested, they've invested, there's all those things. But if you know, right away, if that's from the start, you're seeing that, that's where you need to just back out and say, you know what, push it off to somebody else. You're probably going to find yourself far better off not doing that project than you would have had you done it. It's a couple of my thoughts there. I'll give you some closing thoughts here before we wrap this one up. Yeah, one of the things that brought to mind, especially with software, is, you know, the old business saying you get what you pay for. The problem with what we do in this particular industry is it's not what you get what you pay for. It's how badly is your reputation going to be damaged if you take on a project and you can't deliver for the cost? Meaning, if you don't charge enough and you can't give them the quality that you're used to, you're not going to get the referrals, you're not going to get the, you know, five star ratings, and it could really impact you in the industry. That is actually I think what we're going to cover in the next episode. I think I want to get into that a little bit because there's this is where it does it. I think we're going to we'll spill over into that one and talk about some of the things you can do and some of the things that you should not do as part of reducing costs and cutting corners and some of those kinds of things. And it's this again, this will be, you know, lessons learned and some some painful things in there. And I'll talk to you a little bit of we'll go a little bit into like why I think because we care, you know, why we want to do these things and why they have so much attraction, but also why we have to be very careful because we can get a bite in the buttocks, as they say. And so we have to watch out for that. But we don't bite. We are perfectly fine. Even if we were, we're virtual. So it doesn't really matter. And we've had all our shots. However, you can let us know if you think our topics bite or are really cool by leaving us comments. Shoot us an email and info at developer.com. Check us out on YouTube, the developer channel. We've got these and we've got so much other stuff. School.development.com. You go out to the website, leave us something on the forums, leave us comments anywhere, anywhere you use podcasts. You know, go ahead and feel free to leave comments, reviews, all that kind of stuff. We love the feedback. We like to use that to generate topics and where we want to go, not only for single episodes, but maybe even for entire seasons as we move forward. And at some point in the not too distant future, we'll actually be in season 23. And so now is a perfect time for you to give us some information, see if you can give us some direction for that. Where do you want to go? That being said, we'll let you get back to it. Go out there and have yourself a great day, a great week. And we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Nor Podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.