Ending Your Developer Journey: How to Leave a Lasting Legacy

Welcome to Building Better Developers, the Developer Nord podcast, where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We are Building Better Developers. We are Developer Nord. This is the penultimate episode of this season. I just like to use that word a lot. Just like I said, it sounds cool. You'll always be like horns in the background or something like that, or a little confetti going off or whatever. My name is Rob Broadhead. I am one of the founders of Developer Nord, also a founder of RB Consulting, where we help you take your technology sprawl and turn it into something that is manageable and going to work better for you. We use that. We use simplification. We use automation. We use integration. We look at what you've got, where you need to go and help you build the better vehicle to get there, the better solution to get from where you are to tomorrow and six months, six years, 60 years down the road. Okay, 60 is a little far because technology is going to change too much, but we try to make you as future proof as possible. In the world of good things and bad things, let's see, where do I want to go with that? Oh, good things. Let's start with my good thing. I'm working from home this week. I've got a schedule that allows me a little bit more freedom during the day. I haven't been in as many meetings and stuff like that, which I guess is good in itself. But a bonus was I got some rays of sunshine the other day, just yesterday, I guess it was. In the middle of the day, I wasn't in the middle of a meeting and I was perfectly set up to say, you know what? I can go knock out mowing the yard. So I was able to take advantage, which is one of the values of working remotely, is take advantage of that and be able to get a couple of chores done at the perfect kind of weather and time to do that. So I guess that's my good thing. Bad thing. Bad thing, bad thing. Boy, I've had so much good lately. Bad, bad, bad, bad, bad, bad, bad. I may have to punt on the bad. Gosh, now I got it. I came into this trying to think of a bad thing and I'm really struggling with the bad thing. What have I done bad lately? Oh, bad thing. I'll give you a bad thing. This actually came out of a good thing. So sometimes you have a situation where you've got a, like I had, you have a customer sort of come out of the blue and they're like, hey, we've got to do some stuff. Cool. You dive in, let's do it. And it's not a let's get ready and then they just disappear. It's like you're working with them, you're doing some stuff and you think it's going to continue and you're like sort of ramping up and then it's like, and it doesn't. And then suddenly they just sort of like, oh no, wait, we really don't need it. And it's not, it's not like getting laid off. It's not like a project necessarily being canceled or anything. It's just like you thought that this was going somewhere else or you were moving. It's like you had all the momentum and then suddenly it stops. And it's business. It's what it is. It's just like, oh, okay, well we're done. It's like you're working to the end of a project and it's like, bam, okay, we're done. And it's just like, it's jarring because you're like, you're moving forward really fast on this thing and all of a sudden you're done and it's like, whoa, it's like you hit a brick wall. So that's my bad thing is I just had one of these happen where I was like, okay, I got to give it all this stuff time. And I was like, oh wait, no, I don't. It's done. All right. Moving on. Also moving on in this podcast, we're going to go talk to Mike on the other side and allow you to introduce yourself. Hey everyone. My name is Michael Belash. I'm one of the co-founders of DeveloperNR, Building Better Developers. I'm also the founder of Vision QA, where we help small and mid-sized companies, clinicians, help them with their technology stack, their software, and actually help them with existing development cycles or stacks as well. We can help you really ramp up your development cycles, reduce bugs with utilizing automated testing and redefine or defining what it means to test your software. Good and bad. I'll start with the bad because your good was the fact that you were able to actually get out and mow the lawn. I have not been able to. I have had rainy days every chance I get to try and get out and do my tours in the yard. When you own a large stake of land, that can be very time consuming and doesn't work. Good side, however, is the weather is starting to get better. We're starting to get into fall. I won't have to do that very much longer. I get a few months off from that. So good and bad. Nice. That's a good pair there. This episode, because it is the penultimate episode, we're going to talk about ending your developer journey to some extent. This has been the developer journey, so we are reaching the end. We want to talk about this in two different ways that you end your journey. There is the ending your journey that you were riding off in the sunset and you are no longer caring about being a better developer because you are wrapping up your career. We are not there yet, so there's going to be just some things that we've lessons learned from other people. Take it with a big grain of salt or a big whole salt shaker of salt. The other thing is when you're ending, it's not a career, but it's a path, whether it's a side hustle, whether it is... Actually, I think we also want to talk about, because this is a very good one, is ending a job. When you're moving from one job maybe into your side hustle becomes full hustle or going from one job to another, wrapping things down. And this isn't... I want to take this... We're going to look a little bit more, not just at a project level, but things like, okay, we're moving on to the next thing. Some of the key things I want to... This almost feels like harping on things because there's a lot of this stuff that we've talked about throughout the season. One of the things you want to be able to do when you are wrapping something up, whether it is actually a project, whether it is moving to a new job, or whether you are looking to stop your developer career, to close the door on that, is to document, is to make sure that you have what you use on a daily basis for sure. It's not like how to code, but it is like, what are some of the processes there? What are some of the key things? What are the servers that you connect to? Maybe even usernames and passwords. Particularly one of the things that becomes a problem a lot is emails that are automated that go to you. And this is thinking usually that it's going to be handed off to somebody else. If you're just going to shut everything down and you don't care if anybody ever talks to you again and none of your work is ever going to be carried on, then you don't have to worry about this. It's very simple. You shut the laptop off or your desktop, you unplug it right off in the sunset. That almost never happens. There almost always needs to be some continuity of knowledge and of processes. All the more so when you are leaving a company. Now leaving a company, sometimes they are going to be very, they are going to be very much a part of what you can or should do. Because sometimes it's things like, hey, if you give notice, they're just like, go away. You gave two weeks notice, but you're not going to show up here again because security and stuff like that. There could be other reasons around it as well. But if that's not the case, or if you know it's coming, just make sure that you are putting things in place that your house is in order so that you can hand the keys over to somebody else and say, here you go. Along with this is going to be, like I said, it's going to be things like documenting things. It's going to be looking at who are the contacts that you deal with to make sure that people have contact information for those contacts, emails that come in, making sure that the people that email you know that you are going to be handing that off. A lot of times this includes some sort of a call or something like there were a meeting or something where you're like, hey, Rob is leaving. Let me introduce you to Mike. You're his problem now. You know, so it's you're going to do it a little better than that. But something along those lines that you can do a hand off and you can't hand off by being like it's not a dump a bunch of stuff on somebody's lap and go, here you go. Bye. Have fun. It is actually handing it to them so they can look at it and making sure that they can be successful picking up where you left off. Those are the kinds of things you want to do because you want to put all this work into this or it's a company, whether it's a project, whether it's whatever it is, whether it's your entire career, don't screw it up or tarnish it by not allowing it to be handed off properly. And when you're getting into these things, take a look at like also, if you know you're coming into like if you're winding something down or you're you've got a company that you want to close, make sure that you are signaling to customers and things like that. And this is a good example is there is a company that I deal with just among one of their mailing lists and I just got some of them that said, hey, by the way, we're going to close down at I think it's the end of the year and they sell products, physical products. So it is them saying we're going to be closing down. We're not going to be making those products anymore. If you need those products in the future, they didn't say, you know, here are links, but they said there are other people out there. There are other providers or other vendors. So go check them out. We know they're out there. See what you like, see what you don't like. So they didn't even, you know, they didn't even have to recommend even, but they just said, hey, we're giving you a heads up. This is what's happening so that the customers don't feel like they were hung out to dry. Like for example, actually, I think Michael was there one time. We had, or maybe think of what we had a lunch on a Friday at a restaurant and we came back like Monday or Tuesday to have lunch there again. The business was closed Friday. Nobody knew everybody was like, Hey, let's go. Finally. Great. We come in a couple of days later. We're like, there's nobody in there. The doors are locked. What the heck? They should be open. And we had to dig around, I think, to figure out that it was closed. So don't do that to your customers. Let them know. And that includes your boss. And I know there's always politics and personality and all that kind of stuff. And I hate this job or whatever it happens to be that could come up. Try to take the high road and try to do all the right things to make sure that you're making the right notification. Even if you say, even if you offer to say, Hey, I'm going to like, I'll work on training. I can cross train the next person or something like that. Even if the company doesn't really offer you the opportunity to do that, try to take advantage where you can. Whether it's, you know, if you, if you can't go to that person and spend a little time with them, even if it's like have a lunch or dinner or something to hand stuff off, at least put again, documentation together so that when they sit down and you can say, here's a folder, this is what you need to know. You also have been through more than a few changes in your career. So what are some of your thoughts on these? Yeah. So let me start with the developer journey side of things. So throughout my development career, like you said, there are times when you give notice and you're just walked out the door for security reasons. I've worked for a couple companies where you had to have security clearance to even get into the building. And then you had to add in more security clearance to get into certain areas. If you're in one of those situations and you're going to be leaving, you definitely want, if you want to make sure that you leave in good standings, which you almost always should, even if there's friction or tension within a job, you never know who's going to go somewhere else that you're going to go to in the future and find out your blackball. So always try to leave, think in terms of software, always try to leave things in a better place than where when you started. So in those situations, like you said, like Rob said, try to document what your, what your tasks are. Cause your job role from the day you started to today is probably not the same job role. And if you're in a very small company or a small team, if they need to replace you, if they were to go out and just dig out the old job requirements and try to go hire someone, they're probably not going to get what they need from the next candidate to fill that position or to do that job. So maybe kind of write down your tasks, what it is that you do daily, what is required to do your job. And sometimes that may mean, Oh, they have to go hire more than one person. Another time I was transitioning, love the company, really didn't want to leave, but due to financial stipulations with the company, there really was no more upward momentum. There was really nowhere to go. And you just hit that ceiling and it's really hard because they tried to find something else for me to do to keep me, but they're just financially much better offers out in the industry. I had to leave. However, I did give them 30 days notice because this was one of those situations where I was the lunchman. I was the only person who had been doing this task for seven years. No one else in the company knew what I did or how I did it. So in that situation, I literally had to document everything I did. I recorded videos, I transcribed everything. I sat down with multiple team members to walk them through the process. And I really do feel I left them in a better place than when they started. One, they had almost minimal automation of their application suite. By the time we left, we went from maybe a couple of hundred test suites to over 20,000 automated tests running against your system. But I built that entire framework and that for that company. So really they had no none of this information. So I documented it all. I put it all together. The best part was, which to me was kind of a mixed blessing, was six months later. I'm still friends with my old manager. And he was like, you know, we had to hire two people to take over for your task, but you left us in such a good place. They were able to just sit down, pick it up and roll with it. And that's really a good thing to hear if you're handing off a project, even if you're within the company, moving to a different department, if you really liked what you did, you don't want it to crash and burn you really want it to succeed. So those are some of the good success stories. Bad success or bad stories are when you do give that notice and they literally walk you out the door and you're in that kind of position. It's really sad because you know, and I've heard this more than one times from people I've worked with before. They had no idea what it is that you did. They don't by walking you out the door, they literally shut down the project because they didn't take the time. They didn't think there was no conceptual thought to why, you know, why you left or what it is that you were doing. Do we have everything that we need? So from a business perspective, if you are going to walk someone out the door or get rid of someone, make sure you know what they do. Passwords, emails, things of that nature, like Rob mentioned. Now transition out of our development journey, out of working for a business to side hustles in working in your business. If you're doing this full time, from a side hustle perspective at one time. And Rob, I think we were working in IT for recruiters or something else at that time, but there have been times in my career where I've had multiple side hustles going at once because I wanted to try different things and they didn't quite fit into one, one hat. So I actually spun up five different companies one time for different things. I helped my wife spin up an online store selling knives. I did a kind of a fan base, Dr. Who website that just finally shut down. I actually had it sitting around for three years. I was doing nothing with it thinking, boy, why am I paying for this? If I'm not doing anything with this and you get to that point where it's, you forget about it, you probably need to shut it down, but before you do shut some things down like that, if you took the time to write something or have some intellectual property, make sure you back that up because you want to make sure you have that because if someone steals that, you want to make sure that you can say, Hey, no, that's my property. You can't take that on the flip side of that because of COVID and because I've had some customers that have aged out and some have passed, you will run into situations where companies that you work for shut down. But they'll want you to help them shut down because sometimes you can't just turn the lights off and walk out the door. If you're a financial institution, a healthcare institution, you still have to hold on to patient records or certain financial documentation for years after a company closes. So if you're in the process of helping them shut down or shutting down yourself, these are some things you need to think about and actually plan for before you just turn the lights out and walk away. So you need to kind of have an exit strategy for a business or helping a business kind of shut down. So I'm sorry, go ahead. I was just going to say your thoughts. Yep. A couple of quick hits because there's a, there's a lot of places we go with this. One of them is that when you're shutting something down, one, there's two things to consider in this sort of goes to this, you know, making sure that you have backups and things like that. Is there is your, for your purposes and then also for your customers purposes. Now, a lot of us do software and things of that nature. So you do need to consider things like, do I give a repository or source code over to a customer? Do I, uh, do I give them the keys to the kingdom for, you know, like my GitHub account or something like that, or do I share it over? Do I make them an administrator? Uh, there are a lot of things that you need to consider. Uh, there are, you know, are there servers that maybe you have that you were, you know, they were leasing through you or something like that. You need to move those servers somewhere else for them or allow them to have full access while you're doing that. Now you don't want to be the jerk, which a lot of people have where you just shut it down and now they've got to go figure out a way to do all of that moving themselves, you want to allow them as much as possible access so that they, even though you don't have to do it for them, it's ideal if you give them some way to transfer out, if not at least give them full access so they can do so as much as makes sense for your business. Now there can be, you know, there's issues around all of that. So take each case on a case by case basis. You also want to make sure like Michael mentioned, if you have any IP, any intellectual property, if you're shutting down a business, if there's anything that you put into that, then make sure that you have a way to access that again. For example, when we shut down IT for recruiters, we had numerous things that we had put together. There were classes, there were blog articles, there's a whole bunch of stuff. We still have somewhere, not exactly sure where it is. I could find it if I really needed to it. All of the blog, all of that site, we have the database backed up. We could go really spin that site up if we needed to. I've actually done it once or twice to find like a couple of things. We also have all of our documentation is sitting out on an archived folder somewhere so we can go back and get things. And we actually did in a couple of cases, like I think it was a couple of years later, we came back and actually repurposed some of the lessons that we had and helped another company build out some of their lessons based on that. So you want to do that. When I shut down the Blessing Not Stressing podcast, I still have same thing. I have the database for it. I have the site. I could spin it back up if I needed to. I also made sure one that because it was a podcast, I actually left the podcast site of it up for quite a while. So even though it had been dormant for a long time, it was still live in Apple podcasts, even though I think they showed in a lot of the other podcast places, they showed that it was not active because there hadn't been an episode released in a certain amount of time. Which is funny because if you listen, for example, to Hardcore History, Dan Carlin sometimes will go a year before he turns another episode out. It's still active, but it will show is not active because he hasn't cranked one out recently, but I did take when I did that, I took also copy down the audio for every single episode because I wanted to make sure that I had backups of every one of those if I ever for whatever reason ever needed to go back to them. Because you may want to repurpose stuff. This is particularly if you go from one company to another. Now there can be licensing and legality issues and stuff like that. That it may be what you built you didn't own and you're not allowed to do that. But for the stuff that you did, definitely you want to do that. And a lot of times you need it just again, it's almost CYA, but it's also just to go back to somebody a year later who says, Hey, how did you do that? Or what did you do? Or who did you email or something like that? It is useful to do that. That includes like if you're Outlook, extracting the little Outlook files, your little inbox or whatever, I forget PST files, I guess what they're called. If you're whatever, wherever you can back up and store and archive that information. And it may be that you don't hold onto it, but put it somewhere there to say, Hey, by the way, this is my, you know, maybe it's your personal network drive out there at the company to say, here's all of my stuff. So somebody knows where to go for it. Also be, like I said, be prepared to hand some of that stuff off. Maybe have a meeting where you can say, here's all the code. And by the way, here's the build scripts. Here's how you build it. Knock yourself out something along those lines. That's quite a bit, but you probably did quite a bit, potentially you spent years working there. So there could be quite a bit going on. And there are people that I've talked to that have been involved with where I have, I've helped people shut down their career. Sometimes a couple of cases where it was basically their entire career was spent in this company, 20, 30 years and ramping things down and helping find the next person to replace them. So, you know, it's, I've watched this and a lot of it does come down to, unfortunately enough, a lot of it comes down to documentation, comes down to really making yourself, if you're that person, making yourself sit down. Probably on a daily basis and get your thoughts to paper about the things you do. And it's helpful if you've been there a long time, if you're looking at retiring or shutting a business down, take months, spend a quarter or more ramping things down, making sure that you're taking care of this stuff, your payments are being dealt with so that you can shut all that stuff down. So that there's licenses and stuff like that, that those are all being closed down and they're not auto renewing. All of those kinds of things. That being said, we are wrapping up this penultimate episode of this season. I could say that at least one more time. And I want you to still, we're not done. This is not our last season. We are going to step into the next season. We're going to have lots of nuggets and challenges and key things to do each episode, a good action item for building a better developer. How do you, for you, whoever you are yet, you too, you're going to be that guy in the back, all of you people, including us, what are things we can do to become better developers? And there will be these shorter term and longer term things. A lot of it's going to be about habits and things of that nature. So shoot us an email info at develop in order.com. You can contact us out on develop in order.com. There's a contact form. You can check us out on X at developer, developer, D E V E L P R E N E U R. You can also check us out. We have a Facebook page, we have LinkedIn. We have a lot of those things. You can leave comments out in YouTube. You can leave comments wherever you get your podcasts. You can leave those comments out on our site. If you want to do it, definitely give us your thoughts. What are some things maybe that you would, that you have, if you have some suggestions or some things that you would like to say, Hey, I struggle with X. And I would like not Twitter, but like I struggle with this thing. And I would like to figure out how can I better do that? How can I become better at it? And we're going to have all kinds of suggestions for that related to wherever you are in your career and how you can better yourself. That being said, why don't you go out there and have yourself a great day, a great week, and we will talk to you on the final, the ultimate episode for this season. Have yourself a good one. Thank you for listening to building better developers, the developer 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.