Developer Legacy Guide: How to Make Your Impact Last for Years

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Hola and welcome back. We are continuing and almost wrapping up our season where we're taking a past season going through the topics, throwing it out to AI and saying, what do you think? What should we have done? How could we have done it better? Most of the time, AI does give us some more things to talk about. I don't know if it's better. Sometimes it goes in a very different direction. We'll see where it goes today because we're going to be talking about this was the last one of that season, which was your developer journey, how to leave a lasting legacy. I can almost guarantee it's going to give us some different thoughts on this because we have keywords that it's probably going to go differently. Before we get into that, I should introduce myself and then I'm going to let him introduce himself. See, I'm not even giving his name out. My name is Rob Brodhead. I am one of the founders of Developineur, also the founder of Arby Consulting, where we help businesses assess and simplify their technology. From there, we build clear roadmaps and we help you full grow, fuel growth. We help you to move forward. We help you to figure out how to take where you're stuck. Your wheels are spinning and then we find a way to put a little leverage in there and get you going. We do this by sitting down with you, understanding your business, helping you craft a special recipe, a unique recipe for your business, that roadmap so that you can move forward leveraging technology through simplification, integration, automation, innovation, all of the shuns that are out there. We help you do business better. You can check us out at Arby-SNS.com. We also have like, we've got some deals going on there. We've got some like instant assessments out there and even you can do a self assessment. You can go out to matrix.arby-sns.com. Check it out. Let us know what you think. Good thing, bad thing. Bad thing was, and I don't know if I'm going to tie it to a good thing yet. I was on a call today sitting there like deeply into this conversation. Worked great. Got done and I suddenly realized it was pouring outside and I'd left a couple things out on the porch that I was like, ah, probably shouldn't have. So I had to go through them in the dryer and things like that. So, lesson to you kids, make sure you're keeping an eye on the weather before you like go heads down for a bit. Good thing. And this is actually, I think I've mentioned this before is like, I'm in a little bit of a more quiet time in business. I'm not spending, I've been able to extract myself from working in my business quite so often and so I'm able to work on my business and that has been awesome. It has been so good to be able to knock out some of my to-do list items to upgrade. You can go check out the RB Consulting website. We've definitely done some upgrades there. We've been tweaking stuff, added some products. We're like finishing touches here and there and this also means it will spill over to developers soon enough. I've been already dallying with some ideas there and starting to work towards making that more, bringing it current and also making it easier for you to utilize the huge amounts of content that we have out there. So first, you're going to have to meet my co-host. Go ahead, introduce yourself. Hey everyone, my name is Michael Moulache. I'm one of the co-founders of DeveloperNUR, Building Better Developers. I'm also the owner of Envision QA where we help businesses take back control with customer software, with custom software that's built around their needs, not the other way around. Our focus is simple, great service, smart solutions and a rock solid quality. We build tools that replace frustrating systems, streamline operations and are fully tested to work right the first time. At Envision QA, we combine development and quality assurance to give you software that you can trust and support you can count on. Check us out at EnvisionQA.com. Good thing, bad thing. Let me start with the bad thing. Wife had to take down the bull today. She's a bit depressed because it's finally cool enough. It's just not worth keeping it up anymore. Good thing, fall is here, sort of. The days are getting a little bit shorter. The trees are starting to change color. And if it wasn't just on the other side of hot today, it would have been a perfect day to sit outside and work all day. Those are good days. I would not have had a perfect day because I would have been rained upon as mentioned before. Let's dive right into it. So this episode we are going to go with, as I mentioned, the title was your developer journey, how to leave a lasting legacy. ChatGPT, we're back to that. It came out right away and said, because it loves us, great title again. Wow, we are just knocking them out of the park. You can really connect with developers who want to think beyond just writing code and start shaping something meaningful in their careers. Here's how you could structure and enrich that episode. So let's see how we structure and enrich this puppy. Part one, introduction. What does legacy mean in software development? Legacy is more than old code. It is about lasting impact. Contrast, getting tasks done versus building something that outlives you. Why developers should care about their professional legacy. Now this, honestly, I don't remember us ever really getting into this before. I think we've talked a little, I think it was a little bit more about mentoring and leading and passing it on to the next generation. But this is actually really a cool direction for AI to go with it because I think it is an area that is worth discussing. One of the things we've talked about a lot is building your, scratching your own itch, building applications to help you, to help utilities, to help you, other developers, all those things. And it's also a great way to grow professionally. You can go test out new technologies and approaches and different areas of code. Maybe like, maybe normally you're not a tester, but you get to do some testing or maybe normally you don't do UI, but you get to do UI. I have these conversations with my team on a regular basis where it's like, hey, you can go work on this project and do this thing. And that's going to help you be able to actually like dip a toe into an area that you want to understand a little bit better. I like the idea of, and again, I always like this, getting tasks done versus building something that outlives you. This really goes to work ethic. This really goes to what we want to do is we want to build something that people are going to use. I don't think any of us really want to build something that somebody puts on a shelf and they're just like, okay, I bought the software and I never use it. It is frustrating to us because we probably have invested our time, blood, sweat and tears into it. We want them to use what we've sold them. We really, I think most of us would be rather, we'd rather like earn less money out of it and have them use it all the time than be able to retire on it and have them never use it. Now, I know there's a point where you're like, I'll take the retirement. Thank you very much. But there's very much an idea of, we don't want people, that's our whole point is for so people aren't throwing their money away that they're buying something of value that we're giving the value of our time and our intelligence and our ability to problem solve. And they're returning the value of whatever they pay for it. And I think that's very critical. It's like our why. Very critical to keep in mind while we're doing software development is to basically say, look, we're not here just to write code. We're not here just to like play around with the latest technology. We're really here to solve problems. We're really here to help other people become better, their businesses become better through technology and through the skills that we bring to the table. Thoughts on that? Or actually other ways you may want to go just like AI that was completely in a direction that we haven't been. So I'm going to since I'm a gamer, I'm going to start out with think legacy. All right. If you think if you've been around more than a decade or two, especially with games, you look at what's been around for a long time. Pac-Man, Donkey Kong. These are games that are legacy games. I mean, this is software written in the 80s that is still around today is still being enhanced upon. It was simple. It was great. And it has withstand the test of time. Our legacy can be twofold. It can be software that we've written, or it could be how we handle the situation or how we solve the problem, not just for a customer, but for anyone we've worked for, a company we've worked for, our friends, whatever. As you were talking about this topic, I was thinking back to a company I worked for a couple of jobs ago. They're still using software or test software I wrote, and it is the only way they're able to get the job done. They have not found a solution that can replace what they're currently doing. So there are times when you're working to solve a problem. If you really have the mindset of, anything I do, I want to do right the first time. Now, that doesn't mean that you have to write perfect code every time, but the intent is what you're putting together is a solution that could really withstand the test of time. You write something so good that, yes, it can be expanded upon, but it doesn't have to be rewritten. It doesn't have to be replaced. If you look at the industry, Windows has been around forever. It keeps reinventing itself, but it's still Windows. Linux, same thing. While code can withstand the test of time, how you build this software, how you approach these things, your impact on these projects could be around for a long time. You could be remembered as the person that, hey, this person, put aside personal differences, really put together something solid, that they really did something here. Now, the sad part is, your legacy may not be recognized while you're at your job, while you're currently working on the project. Legacy doesn't happen overnight. Legacy takes time, and usually, legacy doesn't happen until you're gone or have left the project. Yeah, that's a lot of times the legacy is as soon as you leave, everybody blames you. It's like everything went wrong. Oh, yeah, that was that guy that's gone. But it is very heartwarming to hear that something you did is still working, is still being used, and has continued on, lived well beyond your time at that company. Moving on, defining your developer journey. From junior coder to experienced developer, what changes? Skill building, mindset shifts, and responsibility growth. Common milestones, your first PR, leading a project, mentoring others. And I'm going to move right into the next one. Crafting a legacy in code, writing clean, maintainable, and documented code. Importance of standards, naming conventions, and clarity. Leaving behind code that's understandable and usable years later. That, I know I sort of blew through that one point, but it really is the developer journey. If we're talking legacy, let's talk more about the legacy side of it. I really think that that part really nails it. Writing clean, maintainable, and documented code, which basically goes hand in glove with leaving behind code that's understandable and usable years later. If you spend your time, you design it, you write it solid, you document it, you probably are not going to need, nobody's going to need to change it. It is, I know it's sometimes interesting to us, maybe even frustrating to be like, you'll see the name of some coder, some developer from 10 years ago in comments. It's like, oh yeah, that was Bob the Coder. He used to work for us and did a lot of stuff. But think about it, if you were Bob the Coder, and now if you were still looking at your code, now if they're cussing at you, okay, you screwed up. But if there's like, oh yeah, Bob's code is great. Every time I find that, I know what I'm working with. And I literally, I've got a guy that works with me, he has dealt with multiple projects where we have taken over stuff and found a way to grow with it. And there's so many times that he and I have had conversations where it's like, oh yeah, so and so did this code, it was at the top of that file, this is going to be a pain in the butt. Versus, oh yeah, so and so did this section, and it's great. So we're pretty sure it's going to work. It really is like, it's the ability for you to create relationships and trust with somebody you never even meet. And a lot of it comes down to writing the code right the first time, going back, making sure you've done the things you need to do, you've tested it, you've documented it, you've kept it up to date, you've solved that problem, and especially if you do it in a concise way. If you're like, you know, you're probably, you're entire, if you build the whole application, that is not as likely to be like not touched. But if you build like libraries and utilities and certain functions and things like that and they just work, nobody's ever going to need to touch it. So where do you want to go with those? So it's interesting with this one. So when I'm looking at crafting a legacy in code, I see two things. One, leaving behind code that's understandable and usable. One thing AI doesn't touch on here, which I think is a good point here, we live in an age of open source. There are so many communities out there where you can commit your code, put it out in GitHub, open it up to the world. If you do that and you want people to contribute or you think you have a solution that everyone could utilize and improve on, crafting a legacy in code, this is a great example of how to do that. You start out, hey, I've got a project. Great. Stick it in a code repository, drop it out on the web. The problem is if you do not write clean and maintainable documented code, no one's going to use that code. They're going to look at it and be like, oh, well, this may solve my problem, but I can't understand it. It won't work. That is exactly the right way to kind of figure out, are you building a legacy? Stick your code out there. Have people review it. Have people try to use it. If they can't use it, you need to refine it, tweak it, clean it up. If you can do that, chances are you might become the next Apache or the next utils that are out there that people start coming to your Git repository and using your code more and more because it's solid. It works. They don't have to change it. Now, will it stay in the test of time? That depends on the language you're in and how many iterations it goes. But if you continuously maintain it, you could be around for a long time and people will like you, understand your code, and heck, you never know. You might even be picked up for a job based on something you did. I only mentioned that last part because I actually interviewed someone that wrote an open source code, a little training tool for IBM years ago called Robobot, and I had the opportunity to hire him and have him work on my team. He was a great coder, had some personality conflicts, or he was very opinionated on how things like contracting and management styles work, but from a code perspective, this guy was rock solid. His code was good, it was clean, he made sure it worked. So long story short, you never know. If you want to put your code out there and want to start building a legacy, take the first step. Write a utility class or take something that you're good at, drop it out in an open code repository and share it. See what people think about it. You never know. It could build that legacy or it could tell you that, hey, you have room for improvement to get to that legacy. Yeah, I guess that reminds me of I have done that as well. My first job that I interviewed when I came to Nashville, one of the reasons that they liked me, and then actually they liked me, and then later one of my first, actually the first customer that caused me to create RB Consulting came from a project that I had done. My name was on the documentation along with a couple other people. And when they saw that, they were like, oh my gosh, you're that person. You're one of those people that wrote it. It's just like when we talk about writing a book or a podcast or having a blog, when your name is associated with that, then certain people will just be like, they give you an amazing amount of credit. You are now automatically an authority in that area. And that was how I ended up landing a couple of positions is because my name was out there. I had done some work and they liked what was done. And they were able to, and it was even as part of a team, it wasn't necessarily, it wasn't definitely all of my work or anything, but it was something that I could talk to and I could say, well, yeah, we did this and this is how we approached it. And now that kind of legacy was immediate. It wasn't something that came back after the fact, where it was like years later people were like, oh yeah, he was a great guy. We would have loved to hire him. It was like, no, you're a great guy. We want to hire you now. So what you do building your legacy can also help you immediately, not only in the future. Moving on beyond code, your impact on teams, mentorship, teaching others is one of the strongest legacies, advocating for good practices, testing, design, review, security, building a culture of collaboration instead of silos, stories of developers who left a mark, not through genius code, but through leadership and kindness. This, what goes around comes around, karma and all these other things that people have heard a lot of times. I have been blessed by working with people throughout my career that have led been leaders and mentors and things like that. I've done what I can to give that back and be a leader and mentor to people all the time. I literally had a conversation with a lady just the other day that was like, hey, my husband graduated and I want to, you know, he's a, he's a tech guy and he really wants to get into it, but he's struggling for like how to start his career. And that to me was the best conversation I'd had. And I don't know how long cause I'm like, that's what we do, literally building better developers. That's what we want to do. And it's about, it's really not about legacy as much as it is like, look, I, you, everybody that's around you, that's in this industry. We spend a lot of time learning the crap that we know. We spend a lot of time working on our craft. So why not pass that on to the next generation, to the next group, to the next person that's coming up and help them move that much further so we can all move that much further along. And that's what it's all about is using what we've got to help everybody do better. And that's where you're going to impact as a leader, as a mentor and things like that as a manager that you can help impact not only code and products, but actually teams and people. Thoughts on that one. Yeah. So I'm going to take the, I'll take the mentorship one. So teaching others in one-on-one, actually I'll take a couple because the culture of collaboration kind of goes with this because if you mentor, not just one person on your team, but if you foster a environment, a culture of collaboration, you essentially get to a point where you have an environment of kind of paired programming or where, hey, let's open up a Slack channel, jump in. I'm working this problem. Let's all kind of jump in and just kind of circle the fences. You can create mini hackathons. The only way this works is you have to leave your ego at the door. You have to go into these situations, not just being, I have the answer, but hey, what is the problem that we're trying to solve? Get feedback from the team on ways to solve this solution and then tackle it together and treat it like a mini hackathon. And it doesn't always have to be hackathon-ish, but you could do this for a lot of strong problems. So like if someone's struggling and you hear I'm working on this, but I'm kind of stuck on this or someone's stuck on a problem for a day or two, open up a team chat or at the end of your stand-up, say, hey, let's stay on for 10, 15 minutes. Let's walk through this problem and walk through it as a team, like, hey, just kind of debug it. What comes out of these, which is interesting, is not just better testing and design, but you also get a better understanding as a team as how people understand the requirements, understand the work that needs to be done, understand the environments, the code. But the best part is you get to learn how people think and troubleshoot the problems, and then you can kind of all figure out where the strengths are, where the weaknesses and how can we improve. Now that leads me to my favorite part of saying, hey, if you ever want to like get some of that feedback or have those discussions, feel free to shoot us an email at info at developpreneur.com. But also I want to shout out to Brandon, a guy that has been, goes way back in some of our mentoring sessions, stuff like that at Developpreneur. Speaking of hackathons, actually was part of a winning team at a recent hackathon here in the local area. It was pretty cool. I was like looking at the people that were there, and I'm like, I know that guy. I know that name. I'm like, cool. So congratulations, Brandon. That stuff's always fun. And it's really cool to be able to like, so I was saying it's really cool to be able to build out your legacy and your skills as a professional developer. We will wrap this one up though. As always, you can shoot us an email. You can send us, leave us comments wherever you get podcasts. You can leave it out on the developpreneur.com or the developpreneur channel on YouTube. You can catch us at developpreneur on X. You can also check out the developpreneur Facebook page. At some point, we're going to probably have some more stuff, but we just haven't gotten there yet because we're still catching up on social media and stuff. We're, we spend too much time in the business versus on the business and all that kind of goodness. That being said, we do appreciate the heck out of you spending some time with us, hanging out with us and just being out there supporting us. We feel your support. Trust me, we feel those vibes coming in. So go out there and have yourself a great day, a great week. We will talk to you next time. Thank you for listening to Building Better Developers, the Developpreneur podcast. If you 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.