Building on Prior Work

This is Building Better Developers, the Develop-a-Noor podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge, and embracing life. Let's dive into the next episode. Well, hello and welcome back. We are continuing our season where we're looking at ways to take all that hard work and convert it into mastering your career, to advancing, to getting that better job, getting a better salary or any other way that you may look at getting your career and your job to a better place. This episode, we're going to look at building on prior work. We've been doing, the assumption through all of this is that we've been doing this steady getting a little better every day. We've been doing, not necessarily going the extra mile, but we've been doing work where we go the extra, I don't know, three meters or something like that. We've steadily grown in our experience, our knowledge, and our tool set. While we're doing all of these little side projects or research projects or something along those lines, we are essentially creating deliverables of some sort. Maybe not what you would want to turn around and give to your boss or your CEO or something like that. They may not be the most polished deliverables, but they are something that at times, in particular if you're doing it right, you can build on them. Even if you're doing it wrong, sometimes you can build on it. A great example is when we talked about having a personal code repository. This could be for developers, this could be actual source code for people that are in like configuration or testing or something like that. They may be scripts. If you do something, maybe project manager or something along those lines where it's more written word kind of deliverables, then it could be document templates or even just prior versions of a document. For example, way back when I started out more than a few years ago, one of the first jobs I had, we had actually several different forms of requirements documents. There were detail, there was system level, there's all kinds of different stuff. While the general format included a lot of logo stuff and proprietary things, there were key points that I got out of doing that work that I was able to translate into future work of my own. The first time I put together a requirements document, actually I guess a high level design document for somebody. I didn't necessarily start with what I had from these other jobs as a template, but it gave me ideas. It allowed me to put together an outline and then I was able to take what I'd seen actually from at that point a couple different companies and really sort of craft my own template. Then as the years have gone by, I've been able to take a look at past examples of those, of design documents and RFPs and other documents I've put together and tweak them, make some adjustments, update it and steadily make some improvements. In the coding world, that's much easier to do. You've got a chunk of code, you've got a script, maybe down to a function or a method or something like that, or maybe something as big as a series of classes that model some real world situation. For example, maybe it's a registration form and some scripts around being able to build a website that allows you to have users, allows them to log on, allow them to do forgot my password features, stuff like that. These are tasks that we're going to see over and over again. While we may want to make our own adjustments or improvements or may have limitations based on non-competes and stuff like that, it's definitely a starting point that we can go to. This is including all of the stuff we do for our side hustles, for our little test projects, things like that. And by little test projects, I'm referring to, again, for example, those little projects that you do while you're learning a language. Most tutorials, most books that teach you a language will have little applications, probably a strong word to use, maybe applets or miniature applications, limited feature applications we'll call. These things do include solving certain problems. That's part of what they use to teach you. For example, maybe solving a problem of logging information to a file or sending information to a database or submitting a form or styling a page or abstracting certain data items. All of those little tasks are ones that you're going to do over and over and over again. As we are moving forward a little bit better every day, we are also along the way creating a portfolio, maybe even just a raw repository of stuff that we've done that we can actually use to build on moving forward. This should be huge for us. It's going to say maybe not as much in an employee world, but probably just as much as an employee world as it would be in a consulting world. In the consulting world, the bottom line is easy to see. If you spent, picking a number, let's say you spent 10 hours putting together this, like I mentioned before, the user registration piece. Well, now maybe you can take that same thing and redo it for a new customer in two hours. Well, then you just earned an extra eight hours back on that. Now, you could turn around and do stuff as turnkey or fixed bid projects or something like that so that you could take that time that you did, the 10 hours you would have put into that and instead bill, maybe give a discount, you bill six hours and you do two hours of work. But they get 10 hours worth of work at least, maybe more than that because you put that prior work in and then maybe now you're doing a little bit of improvement, stuff like that. It's a win-win situation. It's not quite off the shelf software, but it's along those same lines. However, as an employee, you may think, oh, well, I don't get to do six hours of work or do two hours of work and bill five hours of work or something like that. That doesn't help me, but it does because now you were able to do those two hours of work and get that thing done much faster and you can move on to bigger and better things. You are bringing value to just as you would directly by billing 10 hours of work at say at a six hour level. Well, now you're doing instead of a day's worth of work, you get it done in a couple hours. It allows you to get stuff done faster. It allows you to move quicker and that should over time be something that is going to impress your boss. That is the, at the end of the day, although we don't really do things like lines of code and stuff like that, usually to measure productivity, we do for the most part have some sort of problem solved or tasks completed that is part of what is used to measure us to score how well we're doing. If you've done the work before and you get to come into a sprint or even a day of work or something like that and get stuff done faster, then that benefits everybody. And it's honestly, it's going to be more reliable too, because you've done it before. You've presumably you did something with it. So you tested it to some extent and now you're doing it again. You're testing it again. Over time you have something that is very reliable. It's a known quantity and it helps you not only get the job done, but put together estimates for, even if it's not for your own work, doing it for yourself and for others. Because if it took you 10 hours to do that chunk of work and you're a project manager, development manager or something like that that's trying to estimate stuff out, well, if your team, if you know somebody on your team that is relatively at that level you were at the time, then it should be pretty easy to say, eh, it took me about 10 hours. It'll probably take them about 10 hours to get it done. If they're less experienced, then it'll take them 15 hours or 20 hours or something like that. But what you have is something you can work from. Instead of just trying to sort of, you probably wouldn't be just creating the estimate out of thin air, generally speaking. But the more experience you have doing that, the more concrete those estimates are going to be, the more likely they are to be correct and to actually match reality when all is said and done. So while you can take your prior work and build on it and get yourself to solutions faster or maybe even put some of these prior deliverables and bits of work that you've done together to create something new to solve some new problems, you can also use that experience to estimate what it would take you essentially to do it again or what would take somebody else at some sort of a skewed or adjusted level of time based on how their skill and experiences compared to yours when you did it the first time around. And of course, if you've done it multiple times, then you're going to have a more complete view of what needs to be done because you're going to know, for example, back to the user authorization or user login registration piece. Maybe the first time you did it, you just said, OK, I'm going to register a user and it's going to be a first name, last name, email and password. Well then over time, you realize that, well, email is really not a good login. So instead of the email for a login, I'm going to allow them to enter a login. But then there's issues with logins being unique. And then maybe there's some security. There should be security around the password. And how do I encrypt passwords? People forget passwords. So how do I handle forgetting passwords? How do I validate a registration if I need to guarantee that or not guarantee, but at least feel more comfortable that somebody that registers is real and not just a bot or somebody just spamming my site? There's issues like that that come up. And the more you work through these various problems, the more of those, solving those problems will sort of feed back into your base version of that code, of that solution. And so we get quite a bit of benefit of going back and somewhat reviewing what we've done. Also we're just going to, we don't necessarily have to review it. There's going to be these kinds of problems that are going to be posed and we're going to say, oh yeah, I know I've dealt with that before. And maybe you can put your finger right on where you did it. Or maybe it's something where you say, I'm going to get back to you. I think I have parts of that solution done. Or I think I have a pretty good idea of how to approach that or however you want to spin it or communicate it. But the short of it is, is that you've done it before. Or at least you've done pieces of it before. And so now you can go back and take those pieces you've done and build on top of them. That again, puts you ahead of those around you. And this may even come up in interviews. I have seen situations where there have been interviews, been actually on both sides of it where I'm either interviewing with somebody or interviewing somebody to see if we want to hire them. And there will be specific problems that will come up as part of the discussion. And you'll find out that, oh yeah, this person did pretty much exactly that in their last job. Or they had a little side hustle where they did more or less exactly that. And so while sometimes it seems almost crazy to be looking for somebody that has a very specific set of skills and experience, sometimes you stumble across somebody that has exactly the specific skills and experience that you would be looking for. And when you're doing this steady improvement, you're just increasing the chances, we'll say, of you being that person where you can say, yeah, I've done that before. And a macro skill, you know, up at a very high level, you can think of things like languages. If somebody says, hey, have you used, I don't know, Ruby before? Have you used Angular before? What do you know about React? Things like that. Those may not be any of the primary skills you've dealt with. But because you have pushed yourself and you've learned these new things and you've broadened your horizons, you'll at least be able to say, yeah, I haven't done a whole lot, but I understand the basics of how Ruby on Rails works. Or I haven't done a lot, but I did do some research. And so I understand what HIPAA compliance means. What are some of the concerns that we have to worry about in that? And those are just random examples. You can think of basically whatever it is that you've been working on, that you've been doing to improve yourself. And those are things that may be the linchpin that gets you into a job. That little extra work that you do may be exactly what is needed to get you to start that conversation, to talk about past problems that you've solved in that technology or in that realm. And now not only have you got the door open, they're basically escorting you in. They say, wow, you've already done this. This is awesome. We want you to come do this for what you did before. Do it for us. And you never know how even general problems that you solve will help you on a day-to-day basis. They may not get you in the door, but once you're in the door, it's amazing how often you can look back and say, oh, I didn't do this, but I did this before. If I can go find it, which goes back to the whole idea of having a code repository or document repository or templates or things like that, and preferably in some way that they're organized in some way that you can search or browse through what you've done in the past and go track down some of that older stuff. That can be a challenge in itself, but at least you can stumble around until you find it as your content grows. Think about a project repository or a code repository that's got dozens or maybe even hundreds of projects that you've worked on over the years, big ones and small ones and all sorts of different languages and things like that. But if you can remember roughly the problem you were solving in each of those projects, then it wouldn't take very long to go browse through the projects and go, oh yeah, when I was on Project Acme, I was doing, just because I'm on Ruby on Rails kick lately, so let's say I did Ruby on Rails to create this little data exporting application or whatever it is. But you can go find that stuff that you did, that work that you did. And of course, if you keep a log or something like that or even a blog of what you've done in a given day or week, then obviously that can be searchable and be something that can get you back to your source materials rather quickly. So just keep that in mind as we're going through and we're doing this work. Sometimes we're doing the stuff we're doing on a daily basis. It's not just for us. Sometimes it's prep work for problems that we're going to be solving in the future. At the end of the week, when was the last time you had something occur that you're like, oh yeah, I've got that somewhere and you had to go look for it? And more specifically, were you able to find it? Is this a case where maybe it's a good time for you to go back, take a look at some of that stuff you've done and maybe do a little spring cleaning or organizing or maybe going forward, think of a new way to capture or log that kind of work in a way that will make it easier for you to refer back to it in the future. You're building your own reference library. So if it's something that you can't search, the referring part, the reference part of it can be very challenging. So consider maybe it's time to change a little bit or adjust how you do stuff so that your work is a better reference for you in the future. And that being said, we'll wrap it up and move on to solving whatever problem is ahead of you today. But as always, have yourself a great day, a great week, and we will talk to you next time. There are two things I want to mention to help you get a little further along in your embracing of the content of Developineur. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developineur site. You can also find it on Amazon, search for Rob Brodhead or Source Code of Happiness. You can get it on Kindle. If you're an Amazon Prime member, you can read it free. A lot of good information there. That'll be a lot easier than trying to dig through all of our past blog posts. The other thing is our mastermind slash mentor group. We meet roughly every other week, and this is an opportunity to meet with some other people from a lot of different areas of IT. We have a presentation every time. We talk about some cool tools and features and things that we've come across, things that we've learned, things that you can use to advance your career today. Just shoot us an email at info at Developineur.com if you would like more information. Thank you for listening to Building Better Developers, the Developineur Podcast. For more episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon and other podcast venues, or visit our site at Developineur.com. Just a step forward today is still progress, so let's keep moving forward together.