Your Tools Are Not Your Product
One of the inevitabilities of building a piece of software will always be deciding what to build it with. Try as we might, defining and implementing the “perfect” stack will always be elusive. It’s difficult to admit, but in reality, from the second we start writing code, we’re maintaining a legacy project.
“But wait! I’m using the latest version of Blerga, Flerga, and Derga! And the developer who wrote the boilerplate I’m using said it was future proof! You’re crazy.” Perhaps all of that is true right now. How about in six months? A year? Two years? It doesn’t matter how we frame it: dealing with change is part of the job. The latest and greatest tech will always become the done and over with eventually.
As a mentor, “what should I build this with?” is easily the most common question I get. My answers vary depending on the person I’m working with, but generally the answer is “use what you know.” A truth that took me a long time to accept is that for the majority of the software we build, especially for the first few versions, the stack we use matters very little. Sure, there are some idiosyncrasies that will dictate the need for certain tools to be used, but by and large, the tools we use have very little impact on the product we’re trying to build.
Thinking like this is tricky. It requires you to take off your engineering hat and put on your customer hat. One way to do that is to consider your experience with other products throughout your day. How often, unless you’re just being a geek (guilty), do you think about or concern yourself with what those products are built with? Think about it. Is your measuring stick for how useful a product is what code it was written with? If you know that your favorite app is written in Python (Instagram) or PHP (Facebook), are you just going to stop using it?
Unless you’re bananas, of course not. Guess what? The same applies to your own customers. Just like you don’t with other products, your own customers don’t care what you build your software with. They just want to know that it solves their problem and does so consistently without any hiccups. Funny enough, producing such a result is usually quite tricky with bleeding-edge tools. It’s usually the old and boring stuff that works best.
So, wait…should I not use Meteor, or React, or the other stuff you write about? That depends! How well do you understand those tools? Do they give you some sort of advantage in respect to time-to-market? Do they solve a unique problem in your own product? Or, as is usually the case, are they just the “cool new thing” that everyone’s talking about? Knowing the difference is key.
If you’re going to build a successful product, you have to know when you’re just being a geek playing with new toys and when you’re making a well-informed business decision. This isn’t to say that there’s anything wrong with playing, but if you’re ever going to ship anything, you have to learn how to turn off your nerd ego and say “this will do for now.” The truth is that there will always be some part of your software that’s out of date. Some part that’s not the hottest new thing but works pretty damn well. Something that your code buddies may snark at but your customers won’t even know exists.
As long as your tools enable you to deliver a functional solution, what you use matters very little. Forget about the hype and focus on the problem you’re trying to solve. Your fellow nerds aren’t the one’s paying your bills, your customers are.
