320. How To Survive as a Solo Developer

What do I do if I am the only developer at a company? What systems should I have in place as a solo developer? Are there things I should not do as a sole developer? These are the questions we will answer in today's episode of DevQuestions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_01 0:00

What do you do when you're the only developer at a company? What are the tips and tricks for getting the most done while not making an absolute mess out of things? Solo development is almost entirely a different field than development on a team. So let's talk about the things you can do to survive and thrive in this type of environment in today's episode of DevQuestions.

SPEAKER_00 0:31

Welcome to the Dev Questions Podcast with Tim Corey.

SPEAKER_01 0:35

Software development is more than just writing code. So let's talk about the rest of it. Specifically, let's talk about being a solo developer. Now, before we get into how to survive and thrive in this type of environment, I do want to acknowledge that being a solo developer can look different from situation to situation. It could be that you're building a product on your own or a business on your own, or it could be that you're a solo consultant working for a customer that doesn't have a development department. Or it could be that you've been hired to build custom software full-time for a company where you're the only developer. Whatever the case may be, and I've done all of these myself, there are some constants that can help you out. And just to be clear, this advice can actually help teams of any size, but it's gonna be especially helpful for a solo developer. All right, number one, this is probably the biggest one and the one that's gonna take the most work to work through. And that is you can only support a limited amount of code. That's it's a hard thing to acknowledge. And often people don't agree. And that may be the developer themselves or maybe their management. But either way, this gets a lot of pushback. But here's the reality: at some point, you run out of ability to keep building. And honestly, this happens for a team of one or a team of 200. There's only so much code that you can support. Because when you write code, you don't just write code, complete it, and never touch it again. That almost never happens, and it really only happens for very, very specific situations. For the most part, you are fixing bugs, you are making changes to how the code works, you're adding new features, you are updating it to work with newer operating systems or newer network environments or changes in the way you're doing storage or something else. These things happen a lot. And so when you write code, you're by design adding in some support time to your day for the rest of the time until that code goes away. So it's kind of like building a building. I worked for a college once and they built this brand new, very large building. And during the discovery process of how much is going to cost and how much money do we need to raise and all that thing, that work, one of the things they found that was consistent across a number of different organizations that had built large buildings like this was that you need to set aside a significant amount of money for every year for maintenance. And so their suggestion was at least put 10% of the cost of the building aside and make sure that's for maintenance. And that should be building interest or some other way to put money in and continue that fund because maintenance, the business, the building isn't free, right? You build this brand new building. Think of your house. You build a brand new house. It doesn't matter if it's brand new. Something's gonna break. Something's gonna go wrong. You're gonna need to do some type of work. I just put a whole bunch of money into my house because I had a septic pipe break. So I had to pay for a septic pipe to replace and the digging and the all this stuff. This is normal home ownership stuff. Well, the same is true for code. Things are gonna break. Things are gonna need to be maintained. And so you need to put aside a budget of time to maintain that thing, which means at some point, the entirety of your time, because it is finite, the entirety of your time will be dedicated to maintenance, which means nothing new in theory can be built. Now, companies don't like to admit this, whether it's a building or a piece of software. They don't like to admit that there is any cost beyond the upfront cost. They think that when they when they buy the initial thing, that should be it. But that's not how life works. So when you start building code and you write this really cool application that supports this department, great, that's awesome. But what you're doing then is you are saying, I now have 5% less time in my week because of maintaining that one thing. Which means if I do that 20 times, I'm uh I'm out of work. Like I have no more ability to create new things. This is, and we'll probably talk about it in a separate week, but this is opportunity cost. You've said yes to one thing, which means you're actually saying no to something else. And I know we've all been there where our bosses just don't understand that. And they say, well, I want you to say yes to this, but also that. And we'll talk more about how to maintain that and manage that, you know, in other points. But it's really important that you understand that there's only so much code that you can support. And yes, I know there's AI now, and it can do wonderful things. That doesn't change the fact. Now, yes, AI might be able to make you faster as a developer if you use it correctly, but that doesn't mean that you just have unlimited maintenance now. It just means that you might have a slightly bigger pool to work with for maintaining. So you might be able to do a few more projects before you're out of time again. So, what's the conclusion here? Well, don't just build everything you can build. Build things that are the most important. And you know what? Sometimes the best solution is to say, let's not build something, let's buy something. I run my own company. I write a lot of the software that we run, we use. And that's something that's important to me as well, because I know that the more code that I have written, the more time I spend maintaining that code, the less time I spend teaching. And my primary goal is to be teaching, which means I am very limited in how much code I can write. In fact, I've had my team tell me for years now, we want this, we want that. I would love to build these things. I don't have the time. I don't have the time to build it initially, but more than that, I don't have the time to maintain it. And that's why we have a mobile app for finely, for our um our students who purchase courses. So if you purchase a course, you can get a mobile app in an iOS or Android. But I didn't write that. I had somebody else that wrote that, and then I just pay for it. I pay annually for it because it's easier for me to pay for that and say, you know what, this is cheaper than me spending time maintaining it. So you need to think about buy versus build. Okay. So number one, it's really important to understand this. You only can support a limited amount of code. Number two, automate everything, which kind of feels like it goes against number one, but it doesn't. So you need to look at your entire job and say, what can I automate? And try to automate everything you can. So let's look at this from a purely software standpoint. When you write software, let's say you write, maybe you're writing a desktop app for a company. When you write that code, maybe you make a change to it, what happens then? In a lot of companies, what happens is you go to Visual Studio, you say publish, and then you publish to an executable, and then you put that executable in a place in the drive, or maybe you use a MSI and then you push that out the network. It's a lot of manual steps. Automate that. Continuous integration, continuous deployment. It should be that when you write that code and say, yes, let's commit that to our repository into the production branch or into the production, you know, we mark it as production, whatever you want to do as far as how you designate it. But when you say this goes to production, automation should take it from there until it gets all the way into production as much as possible. Automate as much of your job as possible. That way it's always consistent. That way you're not trying to remember and missing steps every once in a while, which causes more support issues. That way you make sure that you are not doing any more grunt work, any more repetitive work than humanly possible, so that you have more time to support code. Because the more time you have, the more code you can support. Number three, write simpler code. Now, as a senior developer, this is something that you should be doing anyway. But this also means writing simpler code sometimes means not doing all the cool stuff. Uh for a while I worked for a company where we were um rewriting our UI, which was an ASP net um uh just ASP pages. Um ASP or ASP net, web forms. It was web forms. Um I didn't spend a lot of time in them. Um but we were rewriting those into Angular. And Angular can do a lot of cool things. But instead of doing all the cool things it could do, I really trim it down to just a few things because it was easier to maintain. Instead of having things all over the place, or instead of you know having this complex setup that's you know, quote unquote, right, I made a simpler setup because it was faster to maintain. And because it was faster to maintain, it was easier to maintain. We could maintain more code. So write simpler code. Just because you can doesn't mean you should. Okay, just because you can write something complicated, or just you can have all these different layers to make sure that everything has its own specific uh delineation, there's separation concerns everywhere, doesn't mean you always should. Number four, set clear expectations. When you're talking to your boss, when you're talking to the people you're building applications for, you need to set clear expectations. You need to be clear about what you can do, what you can't do, and what the costs associated are. When you're working as a solo developer at a company where you're a full-time salary employee, often people think that your time is free. And it's not. Refer back to point one. You can only support a limited amount of code. So when you are talking about the costs of something, you should be talking, including the opportunity costs. Hey, if I build this marketing app, then I won't have time to build this sales app. Hey, if I if I build this marketing app, I'm not gonna have time to maintain or fix the bugs in this other app. Okay, so you're setting up clear expectations about what's the priority here? Because if that's the priority, that's what I'll do. But here's what you're going to lose. Here's the costs associated. So set clear expectations. Set clear expectations on your time. You know, it if a project is going to take you 100 hours, you should not quote two weeks. You might say, well, I can push a little bit extra. You know, 10 hours extra a week, 50 hours a week, two weeks. No, don't do that. Don't do that. Set clear expectations and say, this is going to take 100 working hours. Every meeting I have takes away from that. Every time I get pulled aside to do a bug fix, it takes away from that. And I only have at most 40 hours a week to start from. So that means two and a half weeks even isn't realistic because I have five meetings a week, you know, an hour each meeting. So that's five hours where I'm not doing this. And I have to respond to email and talk to coworkers and and all these other things, they're going to take another 10 hours a week. So now I'm down to 25 hours a week. That means four weeks to do this project. And then if you pull me aside to do something else, that takes away. And when you're clear about those expectations and clear about what it's going to cost, then it's clear when they pull you aside for a meeting that they're saying yes to the meeting means no to this project. Doesn't mean the project goes away, it just means that project gets pushed off because of the meeting. So saying clear expectations will really be helpful. Number five, be transparent about what you do. Too often, people think that software developers are this black box, right? Where the requirements go in, an application comes out. And maybe don't bug the developer or kind of just poke them a stick and hope that things come out that you want to come out. Don't do that. Make sure that people understand what you do and how you do it. Now, obviously, you're not going to be teaching them, well, maybe not, but you probably won't be teaching them software development. You probably won't be teaching them all the parts of the process you go through. But you should be making sure they know as much as possible about why you do what you do, about why it takes the time that it takes, about how when you give them a demo UI, that's not just Ray for production. Like, and this is also where side note, demo UIs should not look like they're actually usable. They should be, if they're not actually drawn out on something, you should get a tool that makes it look like a sketch. Don't make it a real application. Um, it might be even easier. Um, the fact is, people will misunderstand that. You want to be transparent about what you do, not be confusing about what you do. You need people to understand why it's going to take extra time when they ask for something later. You need to be transparent about how a change now near the end of the process really changes the entire application, not just a little tweak. Be transparent about what you do because they don't know what you do. And so when you come back with something they don't expect, like, hey, it's just a little project, just a little project, and you say, that's three months of work, they don't just feel like you're pushed them off. They feel like you're being honest about the fact that it's a lot bigger than I expected. And tell them why. Tell them why it's not just as simple as a little UI here or there, and all of a sudden the application's done. Okay. So make help them understand what you do because if you're a solo developer, there's probably no one at the company that knows exactly what you do or how you do it. And so if they don't know what you do, then they're not going to have good expectations about what you should be doing or if you're even doing a good job or not. So be transparent. Number six, and I think this is you know life advice for everybody, but it really applies here as well. So let's let's make sure we're clear about it. Don't be a jerk. There you go. That's if you had to have one piece of life advice for everything, just don't be a jerk. But in this place specifically, it's really important because you have the opportunity to be a jerk. When you're the sole developer in a company, sometimes the company feels like you kind of have a stranglehold on them. Because if you left, like what would happen? Like things would fall apart. Oh my goodness, we wouldn't know what to do if we don't know what you do. So you have the opportunity to be that jerk who you know everybody kind of hates, but you have to put up with because you have no other choice. Don't be that person because that leads to resentment not to working together as a team member. That leads to them trying to figure out how to get rid of you instead of being thrilled that you're there. Okay. Don't be a jerk. It's going to make your life easier. If you're a consultant, it means you probably get called back for the next job, right? If you are a full-time employee, maybe you you miss out on the layoffs, right? Like there's a really it's important to understand that just because you're a software developer doesn't give you a license to be a bad person. Okay. Don't be a jerk. Being a solo developer can be a great job. I I have loved it through my career. Like I said, I've done it a number of different ways, and it's a lot of fun. But it's you can also make a mess out of it. Okay. Use these tips to survive and thrive in the role of software developer. Thanks for listening. As always, I am Tim Corey.

SPEAKER_00 18:22

Thank you for joining us for this episode of Dev Questions. When you're ready to learn to think and code like a professional developer, head over to IamtimCorey.com and enroll in a course.