Deploying an app is getting cheaper and easier. There’s no shortage of people looking at their job and coming up with a software idea that can streamline a process. I’m all for this. After all, code is merely a meticulous business spec that’s executed by a computer. If you can nail down a protocol for a process, this can be coded and run on a server. However, there is still an annoying trend of people who act like going through this process is like managing a spy program. They want you to sign DNAs for merely talking to them, and their scared that someone is going to run off with their ideas and code and beat them. If you come across someone like this, do yourself a favor and run a mile, because it screams that they don’t know what they’re talking about and they’ve never gotten a successful project off the ground. Of course, there are some rare exceptions but in general stealing, code is a waste of time. I’ve lost count at the amount of code I’ve open-sourced and put on public repos. I’ve never come across anyone who’s made it big from the code I’ve pushed out there.

First of all, you have to understand that no codebase is perfect and it’s because there are trade-offs on what you do depending on your resources and current business goals. I haven’t come across a codebase yet that doesn’t have some highly coupled legacy code that is a nightmare to untangle, and is so brittle when you change one thing, something else breaks. I’d hate to inherit that. If I’m starting a new project, I’d be mad to instantly bind my hands with that.

Then there’s the mind-reading. If the team who built the code is perfect then there’s good documentation. However, even with good documentation, you will come across dark patches that you will struggle to understand. This is sometimes due to a lack of understanding of the bigger picture in this context. It’s unlikely that you also knew the style of that particular coder and understand their future plans. And then there are the bugs. Every codebase has bugs that will inhibit growth or cause issues if new features are added. Good luck managing that blind. If I stole the code, I’d burn hours trying to mind read and fight fires blindly. With high-level languages and mature frameworks, it would be quicker and safer to build your own.

Hey, what about infrastructure and deployment. Especially if it’s microservices the DevOps code will be engineered around the needs and specific hardware setup of the company who owns the code. You’re also forced to use the tools and frameworks that they have chosen. Again, it would be quicker, safer, cheaper and more flexible to just build your own infrastructure.

There are also improvements. Every coder in the team can probably point to a particular piece of the code and exclaim that they would in hindsight do it differently if they had time.

Wait a minute, didn’t I say at the beginning that code is basically a meticulous business spec? Oh yeah, I did. Let’s hope that your business plan is pretty much the same as the business plan of the company you stole from, with the same customers who have the same problems and needs. Trying to ram a codebase with legacy tech debt, that you will not fully understand, with unknown bugs and issues into a business model that it wasn’t designed for pretty much qualifies you for a head scan to ensure you don’t have any underlying pathology as to why you’re doing this.

There are some rare cases where stealing code is a big issue. To reference the TV series Silicon Valley, if you stole their revolutionary compression algorithm this would be a good win (though maintaining and quality controlling it would be a nightmare as you don’t have to expertise and systems in place). However, for the vast majority of code, it’s just dumb. In fact, a big selling point that recruiters tell engineers if they can is that a project is green-field, meaning you get to code from scratch and that there isn’t an existing infrastructure.