An engineer working in a startup walks into a bar. The bartender doesn’t respond. Because the engineer never walked in at all. He was busy debugging a race condition that cropped up on production. While redesigning the landing page. And setting up a Redis cluster in some EC2 VMs.
Developing on a small team can get tricky. Always too much to do, in too little time, with too little manpower. I’ve grappled with this problem for a while, having never worked on a team larger than 10. Ever. And after many late night crunches and Sunday morning extensions, I managed to land on a half-solution. It’s both better and worse than you think.
First, an aside on culture. One of the things I enjoy the most about tech is the sub-cultures. You think politics is divided? Get into tech. There’s the REST gang vs the GraphQL bunch. Microservices vs monolith. Unix vs Windows. It goes on and on. There’s a schism for everyone. Since tech allowed us to do everything, we did exactly that. Which is both a blessing and a curse.
On one hand, you’ve got super niche languages like Go roaming in the wild. This is curious: Go was invented for the sole purpose of making large, high-performance programs running on multi-core machines. Things that would’ve had to be written in C+ or Java. And these days, few people have that problem. How many of us are working on codebases with millions of lines? Not many. And yet here I am leading a tiny team building microservices entirely in Go. The kicker: We don’t even anticipate much traffic. After all, how many people are going to use a trading bot platform? And yet here we are using a language designed for scale, when we have even less scale than React has elegance. Tech is so fragmented that we’ve got these little pockets we can make our own. There’s a niche for everyone.
But on the other hand, there’s plenty of noise to sift through. I mean, you’re hearing nice things about Go from me. But it doesn’t take long to find someone who’s not a fan. And you can do that with any language, framework, or ecosystem. So many people have an opinion on so many things that it can be hard to figure out the right thing. Which leads us to the technique my team and I used to build quickly. My half-solution: Ignore what everyone else says.
The idea is to treat all external tech opinions with skepticism by default. First, distrust. Then, verify. Then, consider. Doesn’t matter if it’s something old like REST or something new like React version 58.4.1. Skepticism forces you to reevaluate all “best practices”. Dig down and learn how and if they’re actually useful. How does that help with saving time? Because we engineers are all too happy to mess around with some weird library or package we don’t really need. And avoiding these tangents would save more time than you realize.
For instance, TDD. My arch-nemesis. A critical part of writing robust software is writing tests. The problem is, says who? That’s right: We scorned one of the oldest tricks in the book. Skepticism, people. Doesn’t help that we haven’t had much luck with testing as a team. It has always caused more bugs than it fixed. So we thought, “What if we just abandon testing this time? What would happen?”
The answer is, we’d move faster and still have roughly the same number of bugs. How do I know? Because that’s exactly what happened. Not sure how sustainable our solution is. But it’s nice while it lasts. Still, we always need to be on our toes. I guess that’s the price of abandoning the well-lit path. You’ve constantly got to watch where you’re going.