The 3 Worst Pieces of Programming Advice I’ve Ever Heard

Stay in tech long enough, and you’ll bump into some spectacularly tragic advice. Engineers are still people, at the end of the day. And people come in all shapes and sizes. Many of them don’t know which way is up. Which isn’t hard, especially in tech. Breaking things and being unprepared is woven into the fabric of our industry. But not all of us can move fast and break things like Facebook. Some people move fast and break everything. And that’s where the most egregious programming advice I’ve ever heard comes from.
1. Don’t Do What Everyone Else is Doing
Innovation: The North Star of every engineer. It’s tattooed on your neck. Engraved on your engagement ring. You write about it in your diary every night. You can’t be a programmer without being an innovator. And what does innovation mean? Be different. Set yourself apart however possible. Don’t fit in. Make everything the fresh way — your way.
At first glance, this makes plenty of sense. Especially when you’re in a dingy room with four other people, plotting and scheming about your billion-dollar idea. But most of us don’t realize something while planning to start the Uber of pancakes: Necessity is the mother of invention.
From what I’ve gathered speaking to people who have been doing this longer than I’ve been alive, innovation is the last resort. I mean, we’re talking about invention. Making something that has never been made before. And there’s a reason it has never been made before: It’s super hard. Prone to failure. Incredibly risky. So why would you take that risk unnecessarily?
It’s far too easy to weigh the benefits of innovation while forgetting the cost. And the cost is failure. Which is almost certain, by the way. That’s the definition of innovation. If success were likely, it wouldn’t be innovation. So doing what everyone else is doing is actually a great idea, most of the time.
Because there’s one nice thing about doing what everyone else is doing: Everyone else is already doing it. Which means it works. Isn’t that something we’re supposed to care about? Things actually working? A career in tech isn’t supposed to be a series of potshots. Something tells me we’re supposed to build things that are actually useful, instead of amassing a museum of failed experiments. That’s why this piece of advice has often led me astray.
2. Do What Everyone Else is Doing
If you didn’t skip the last section, you’re probably scratching your head right now. But this one is best illustrated with a story: Once upon a time, there was an ordinary startup that had a decent chance of making it. Solid team. Nearing product-market fit. All was going well. And then, they heard that every company everywhere is switching over to microservices. The end.
You know how that story ends: Catastrophe. Microservices are all the rage, right now. Not unlike other trends that have since passed. Remember when Docker first started getting popular? You would’ve thought they found the cure for cancer. Or what about the messaging widget boom? Anyone remember the Drift hype? Or what about that phase when all the new startups were building their MVP with Rust?
The truth is, following the pack isn’t always the brightest idea. Because the pack tends to sway too easily. Making rational decisions based on your own needs is always the wiser choice. Chances are, what suits you best doesn’t suit most people.
For instance, I’m part of a team building a trading strategy backtesting tool. It’s basically just a JavaScript frontend with some charts hooked up to a Go REST API. Nothing crazy on the tech side. But the utility is in the application of that simple tech. Testing trading strategies on historical data is usually a pain. It’s more straightforward to become a US citizen. So we make it easy and more interactive. But enough of the shilling, it’s not like the product is ready yet. And that’s exactly my point. That’s the problem, ladies and gentlemen, with doing what everyone else does.
We should’ve ignored the mainstream advice, which is to make the product solid before releasing. Apparently, traders are serious about their work, and an experimental product would rub them the wrong way. But we should’ve just pushed an MVP off the ledge long ago. In fact, it could’ve even been a BFP. A barely functional product. Because it turns out people don’t really mind if things don’t look right. And the early feedback we get when others mess around with our prototype is golden. So we should’ve let them in from the start. Would’ve saved months of unnecessary development.
Because making charts in JavaScript isn’t like putting your pants on in the morning. Nothing cooperates. All the little controls to wire logic for. All the states to manage. All the data to process for all the subtly different yet distinct views. All the layout and rendering calculations for multiple screen sizes. It’s not fun. Especially when you find out you didn’t need to do most of it, in the first place.
So following the other sheep? No, thanks. Do your own thinking. That way, you won’t have to do someone else’s work.
3. Build as Quickly as Possible
We all know the success story of some startup who pulled a golden rabbit out of their hat in two minutes flat. You know, the guys who called Sequoia Capital the day after they started working on their MVP. The guys who finished their slide deck in the waiting room before their first pitch. And then went on to secure $30 million. For their Series A.
Building as quickly as possible is a staple of tech culture. But is it always the right thing to do? I mean, pushing something out to collect feedback seems like a good plan, doesn’t it? Validating the concept. Making sure you don’t build what you don’t need. But that’s the catch, isn’t it? It’s hard to not build what you don’t need if you build hastily.
But it’s not just that. Even when you do build, it’s easy to mess things up if you don’t spend enough time on the design. Writing the spec is probably more important than writing the code. Figuring out what to build is more important than building it. Because the former has the potential to save you massive amounts of time. Who knows? Maybe you don’t need to optimize that piece of code at all. Because it doesn’t need to exist in the first place.

About Author

Comment here

eighteen + thirteen =