Geek Out Or Build Things, Don't Do Both

The software development world moves at a frightening pace, there's always a new language, new database, new framework, new browser feature, new HTML addition, new API, new SAAS or new something else. It's common for coders who care about their craft to want to stay up to date with the latest things in their area, to try out that shiny new database, to write something in Rust or whatever the new language is this month, framework X is supposed to do things better than framework Y so lets use that. The temptation to tinker with shiny new stuff is strong, many programmers will have started their careers because they wanted to know how that computer worked and for people who are really into their programming, that desire stays with you.

But geeking out with a new language/DB/framework/whatever doesn't always sit well with building stuff and shipping products. I've seen many projects derail because people have disappeared into the woods with some unfamiliar technology and they have ended up spending too much time learning about and working around uncertainties and unknowns.

I have two modes of working, either I am making or tinkering with stuff for fun or I am building products I want to ship. When doing the former I will pick up anything that looks cool and try and use it, if it doesn't work quite as expected then no harm done but knowledge has been gained and maybe some new ways of working have been learned. If I'm building a product I want to ship then I stick absolutely with technologies I have known for a long time and understand well.

Sticking with tried and tested solutions does make the shippable projects a bit boring to build, it does feel a bit same-same, but by sticking with what I know I massively increase my chances of building a robust and maintainable system that meets requirements; it might not be a cutting-edge and exciting system to build but it will work . Also, because I know the technologies I am using inside and out I can give better estimates about how long it will take to build, there are fewer surprises when you know your tools.

An important thing to remember when building shippable products is that the customer rarely cares about how you built the system, they only care that it works. Still using MySQL instead of a NoSQL alternative? Your customer is not going to care as long as it works, scales to need and meets their requirements.

There is always something better being released, Rust is better than Go, Mongo is better than MySQL, React is better than Angular and so on for eternity. If you keep grabbing for that so-called better option then you will never have a set of battle-hardened tools at your disposal that you can use to build systems that you can trust. You will leave uncertainties and grey areas, some edge stuff that you can't bet your house on because you don't know that new technology that well. Better, in my opinion, to stick with what you know when the shipped product matters more than how it was built. I still use MySQL for almost all of my projects, I know it has some failings, I know there are alternatives and different ways of storing things, but I also know its quirks, where it does and does not work, how to configure it, how it performs, how to scale it, back it up, it's an old friend that I can rely on.

Enterprise software development gets a bad rep, and rightly so in many ways, but one thing I think it does get right is that it doesn't typically race after the newest tech, it sticks with what it knows and minimizes its risks. I'm all for cool new stuff but I think it has its place and if you want to see your product shipped in the shortest time possible, with the least amount of pain and fewest surprises you should stick to what you know. Building your new product using Rust with a React front-end will be an interesting project if you've done everything up till now with Spring and jQuery, you'll like it, everyone on Hacker News will like it, your customers might not.