One-Offs and Side Projects

This is Building Better Developers, the Develop-a-newer 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 taking all that hard work and turning it into a little bit of career, a little bit of job. More happiness, satisfaction, and all those other good things. Since we're spending every day getting better, we might as well get something out of it. This episode, we're going to deviate a little. We're going to talk about what we'll call them as one-offs and side projects or the kinds of things you run into where it's not really the recommended approach. It may not be the standard language, the standard tool. It may not even be a common one, but for some reason, you have that skill and either you're asked to use it or some of this goes into looking into when it makes sense for you to make use of those skills. This goes back quite a bit. One of my favorite stories, I guess it was. It would be about how things have progressed over the years is a look back at Linux when it first started out. Well, I guess in its early days anyways, maybe not when it first started out. There were people that were adopting it and finding that it was actually really good. They basically had an option those days of Windows 3.1 or 3.1. Windows NT maybe was coming out. Windows 2000 was several years away. Apples were out there, but they didn't exist in the way they do today. They weren't available like they are today. They didn't have the software that they have today. Some people get frustrated because they were trying to do things like maybe just put up a little departmental web server or work with a little lower end database or something like that. They had a little departmental project they were working on. Or maybe they just wanted to get stuff done a little faster and they got tired of the Windows reboot cycle. They looked to the world of Unix, which was probably more diverse even than it is today. There are a lot of places that have been gobbled up over the years. But there weren't really desktop versions out there for the most part other than Linux. It had a couple of different and even then maybe dozens of different distributions. I'm not sure how many existed back in the early days. But what would happen is people would go and grab a...they'd have their own little desktop or something close to that, maybe a little home-built server. And they'd park it under their desk at work. This is before wireless. So people had wired connections and things like that. That was how they would sneak Linux into the company. Is they basically have a little departmental server. They'd make a little Linux machine. It was cheaper than going out and buying a Sun Solaris or HP UX or something like that. So it worked for a low budget and it provided speed. Some people, I was one of them, would dual boot. So they would, when they could, would work in a Linux environment and when not, they could always flip back to Windows if they needed to. And it just sort of evolved from there. Not necessarily catching hold completely, but what you saw was people that had a tool that worked. And maybe if it didn't necessarily work, you could always argue that. It was something they enjoyed. It's something they wanted to do. It was something that made them happy and satisfied at their job. And rather than jump through a bunch of hoops or try to get the budget for something bigger, they went for this easier approach. And the next thing you know, you actually had situations where people had to support it. You had companies that had multiple users on a system that was built on a Linux machine. And now you have to go make sure that you've got people to support it. Maybe an employee moves on and now you have to have somebody that can do whatever programming or configuration they did. And therein lies the rub, I think. It makes sense sometimes to veer from the standards. Let's say you're a, I don't know, let's say you're a power builder shop or a Salesforce shop or something like that. And you need to do a little scripty type application, maybe a little desktop application or something. You don't want to use this big, huge behemoth of a software to do these little scripts. It just doesn't make sense. For example, C Sharp's gotten better so you can do it across platform. But back in the day, a few years ago, you couldn't run it basically. Before the Mono project, you couldn't run it on anything other than Windows. So maybe you were a C Sharp shop, but you needed to write a little project, a little process or service or something like that out on a Unix machine or Mac or something like that. And so you can see C Sharp wasn't viable. Or maybe it just makes sense that you're like the Salesforce type thing. Maybe it just doesn't fit. And we've talked about the before where you have languages that have certain things they do really well and maybe some things they don't do well at all. Just to be a blatant example, it would be SQL. If you want to deal with a database and relational databases, use SQL all day long. If you want to build a desktop application in a Windows environment, SQL is not going to be a tool that's going to work for you. Some of these things maybe you can find a way to make it work, but sometimes it's more trouble than it's worth. So that's one of the things that I think is what we often will use is our leverage or our crutch to say, okay, we need to do this task. We have this project or this application and our standards don't fit it. Our standards are not a good fit to get this thing done. So rather than try to have another project that fits our standards and falls under our normal technology stack, it makes more sense, especially depending on the application, it makes more sense to just do this thing in outside of our normal stack, as we'll call it. And I tend to refer to these as one-offs and maybe proof of concepts and things like that because that's more often than not what you're going to end up with. If it's a situation where you're changing gears and you're going to do dozens or have a flagship product that's going to be done in this new technology stack, it's a whole different equation because then you're looking at, all right, do we veer off of our, basically maybe migrate off of our current stack to this new stack or do we have to add another stack that we're going to support? And of course, supporting that does mean you have to have resources that understand it. If you're a C-sharp shop, always hard to say quickly, and you want to go to Ruby, if your developers don't know Ruby, you're up a creek basically, or they're going to have to learn, or you're going to have to go hire Ruby developers. Or if you've got one person that knows Ruby and they build a bunch of applications and they can be the smartest person you've got or whatever, but if they leave, those applications are useless or you've got to find a Ruby resource. So there is a cost to doing these one-offs. Whenever you expand your technology stack, there's going to be a cost to it. Now as a developer or consultant, you may not see that, you may not feel that because you're not the one that's going to be paying it. You're going to be the one that's, you're off doing this project and probably a technology that you prefer or enjoy, and it's the people behind you that are going to have to deal with that. But that doesn't mean that you should never expand the technology stack. And I did sort of have a spoiler alert at the beginning because really the key is things like proof of concepts and one-offs. Situations where you don't really need this thing you're building beyond a short-term or very tightly focused purpose. And a proof of concept or a one-off would be perfect for that. A one-off being something that's, hey, we have to do this one time. Maybe we're migrating data from one database version to another, and we've got to pull the data out of one, push it into another, and do some transformations. Essentially some sort of ETL process, but we're only going to run it once. At the end of the day, well, maybe not once. We'll run it several times in tests, but we'll actually only run it once when we move from production to production, and then we never have to see it again. That's a perfect opportunity to go to whatever technology you want because it's really whatever works best in the moment. Because once the moment's gone, you don't need that thing anymore. An interesting argument on the proof of concept or a demo or maybe a minimum viable product, but probably not an MVP. I'll talk about that in a little bit. One of the things that you can do that is a benefit in a POC of getting out of your normal stack is that it gives you some definition around that POC that says this is a proof of concept. If you want to move it to a production product, then you really need to move it out of that technology into your core technology. In that case, it maybe makes a lot of sense to do your POC in something that's different just so it doesn't end up being a foundation for a product down the road. The features can be there and things like that. Maybe you can steal some code here and there, but one of the worst things you can do is put together a POC thinking it's a POC, and then that becomes the foundation for a big product down the road because you're probably going to do it very quick and dirty. Dirty is a relative term, but you're going to do it quickly. You're not going to spend the time architecting stuff. You're not going to think through much other than whatever that primary problem is you're trying to solve. Your POC almost by definition, if it's done right, is going to be limited, which is different when we talk about an MVP. An MVP almost by definition, and I would think, I don't know many people who argue against it, by definition, you're going to build off of it. The whole point of an MVP is to get us to a point that it's viable and we can do something with it, but we don't stop there. The thought always with an MVP, or always in my experience anyways, is that you build the MVP and then you continue on building on top of what you did in the MVP. So where a POC, it may make sense to get out of, off of your primary technology stack. You go to minimally viable. If you go to an MVP, then you really need to be within your technology stack or part of that project needs to be an understanding that we are moving to a different technology stack as part of it. Now I say all of this because these, all of these types of projects, for whatever reason, you move off of that primary technology stack, it's just, it's an opportunity for you to shine. It's opportunity for you to show off some of the things that you know that are not in the normal tech stack. It allows you to do things that maybe you wouldn't do on your normal day to day tasks and lean into some of the other skills that you have. In some cases, this is even situations where people have brought in side projects and past projects that they've done where they built a tool to do whatever it is that they built the tool to do to solve a problem. And oh my gosh, you see that problem again and you say, Hey, I have a tool that already does that. So you bring it in. Some people do that and they see it as an opportunity to make a few bucks and say, well, you know, Hey, I'll bring this in, but I'm going to license it. You guys are going to have to license it or purchase the product or something like that. I have mixed emotions on that because you are an employee and you're bringing that in. It is something that you built elsewhere, maybe that you built in your spare time and you're looking to get something out of it. But if you're doing it sort of a backdoor way to say, well, you know, Hey, I can use this product and you're not upfront saying, Hey, there's this thing that's on the market. I happen to write it. Maybe we should look into it, especially if you're not the key decision maker that ends up writing a check to your quote company for that software. Then okay, you know, that just you happen to know about something that's out there. It's a little different if you're sort of working it in in the back, you use it and then you come back and basically say, Oh, by the way, you guys need to actually pay for this. Maybe you do it in demos and early on and then later down the road when you basically have your company hooked, then you sell the product to them. If you're doing it to in general, I think if you're doing it to just make a quick buck, probably don't want to. If you're an employer, if you're an employment situation, if you're a consultant and you sell services anyways, maybe that makes sense. But as an employee, that's a little bit of double dipping and things like that. I'm sure it's legal and I don't know where it falls in the ethical sense, but that's just me. For yourself, it may be something where you see it as a great opportunity to do something with your side hustle. Sometimes it is. Sometimes it is a way to take what you did with your side hustle and get some buy-in from your company or your employer. Maybe you get to do a side product that they want to build that you team up with them or Maybe they become a customer of yours, much like if you leave a job and you go back and essentially consult for the job that you just did. But there's a lot of value in going back to this. There's a lot of value in moving to that other technology for yourself as well. Besides just generally gives you something a little different to do. You're in a different stack. It's a change of pace. It can revitalize you a little bit and remove some burnout. It also can be a way for your company to dip their toe into some other technologies and stacks that are out there, which is valuable. You don't want to be stuck in something that's dying. Maybe you bring this stuff in, you introduce some new direction that will maybe be a jumping off point for your organization to get out of a dead technology and move into something that's a little more modern. So there's a huge amount of things to consider from the business side as far as there's value or not. When you have the opportunity, when you look at something you say, wow, this makes a lot of sense to do it in a technology that I know but isn't our primary stack. Really, I think it just comes down to be as transparent and informative as possible about it. You can say, hey, here's something I was looking at that maybe will help us out or here's something that I worked on in a prior job that I think would be a good approach for us. Don't get in a situation where you let your feelings get hurt if they say, no, we want to stick with our primary technology stack. Because understand that that is always going to be a viable answer, a potential answer that would make sense from their point of view. You may disagree, but at the end of the day, they make the decisions you don't. So when you're taking a look at these other technologies, when you're building a proof of concept, when you're doing a one-off, while it makes, I think often it's, especially for those of us at Code a lot that develop a lot of new stuff, that spend a lot of time in new technologies, we want to use the new things. It's just bells and whistles in general, but the cooler, newer technology, we want to make use of it. But take a deep breath, step back, and do it in a way that is intentional. Go to your boss or whoever it is and say, here's how I want to approach this. By the way, this is the technology stack I see as being the best one for it. I know it's outside of our normal, but here's why this makes sense in this case. It's a one-off. Or maybe this is something that we want to look at as a potential pivot essentially to a new technology in the future. When you do that, as opposed to the story I started with where people just start sneaking running basically these renegade servers in their departments that drove people nuts for a while. Instead, be open about it and say, hey, here's what I'd like to do. Here's how I'd like to approach this. Here's the pros and the cons. Let them make a decision and then move forward based on that decision. It's a good story to be that renegade that stuck something in and managed to change an entire organization. But it's sort of like Hollywood movies. It's not necessarily the way it always goes. Just like in Hollywood, you always have that loose cannon law enforcement guy that ends up being the hero because everybody else is an idiot. That's neat in the movies, but that's not generally how things go in the real world. You may think everybody around you are idiots, but people know stuff and do stuff for reasons that we may not understand. So you're going to be much better off. Have that conversation. Pull that door open and say, hey, here's something I see as a possibility. This is a direction I think we could go and here's the reasons why I think it would be valuable. I think you'd be amazed, especially if you haven't done this many times before. I think you'd be amazed at how well those conversations often can go. There's going to be times you're going to be disappointed, but I think a lot of times, you'll find out that you will be very happy that you had that conversation. Challenge of the week. When was the last time you had to build a one-off? Did you use the technology that was the stack for that company or did you fall back on whatever was most comfortable to you? It should be a pretty quick little thought exercise there for you. So we'll keep it a little less challenging than normal. I think it's one of those things that it's worth thinking about and maybe you'll have a little more insights. However you did that, however that progressed, maybe a few more insights into how you do things and maybe there's some mistakes you made that you can correct and do it better the next time around. But no matter what you do, as always, I do want you to get out there and have yourself a great day, a great week, and we will talk to you next time. One more thing before you go. Developer Noor podcast and site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us, it'd be great if you go out to developernoor.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. So you can go back and have yourself a great day. Thank you for listening to Building Better Developers, the Developer Noor 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 developernoor.com. Just a step forward today is still progress. So let's keep moving forward together.