An early concept you learn in programming is that it’s not smart to get caught up trying to reinvent the wheel. If a software solution already exists that can get a job done, it’s typically a good idea to noddingly make use of it and move along to the next issue.
Of course, when I think of the traditional leaders in tech at large, I realize almost all of them were contrarians who refused to make use of the typical ways of doing things. Steve Jobs told everyone to "think different" as long as they did that thinking with an Apple product. Bill Gates did a lot of unconventional things to get Microsoft off the ground. And so has Elon Musk at Tesla.
But just like those people you hear about striking it big trading stocks, there is survivorship bias at play. For every contrarian success story that you hear, there are probably hundreds of failures that didn't make the news because no one wants to read about that.
In my programming career, there have been a few times when being a contrarian was good, and just as many times where I should have kept my mouth shut and stuck to the textbook or company charter.
When being contrarian is good
There is more to being contrarian in software engineering than saying "that code sucks" or "I don’t use these tools." When to pick your fights is part of the game, but making your case can be just as important. Think rewriting a codebase can be fun and prove net-positive returns? Politely sketch out why.
Of course, situations do exist where the stakes are so high that the message is more important than its packaging – like when not objecting to bad technical procedures can ruin a project or company. I’ve also been there.
When you are certain that you know best about the technology at hand
I can remember multiple times where I voiced my opinion, but I didn't push hard enough. One was when the business — that shall remain nameless — decided on a payment processor.
If you worked in e-commerce about a decade ago, you'd likely know what company I am talking about. It was one of the few options back then, and this company's still around today. Guess what? Not much about the service has changed.
Stripe would have been perfect for what was needed. We needed payment processing that would work well with React. Well, the company's choice did not. In hindsight, as far as engineer objections go, connecting the technical dots for decision-makers on this would have been on the easy side. But I didn't put up any kind of fight, never mind a cogent pros-and-cons argument, so we ended up having to fork the React component they suggested to add the functionality it needed. This costed the company about two weeks of our engineering time to add a simple payment form that could have (and should have) taken hours.
When the consequences of not causing a stink can sink the whole company
Sometimes, it's good to let old software die. I've worked on multiple projects that were over a decade old and the closest thing they resembled, in reality, was a Rube Goldberg machine.
One ran two separate versions of PHP in different parts of the application. It took days for developers to set up their development environment. It took more days to fix some things that seemed like simple bugs, but we had to add features to comply with the law. That took many more days, too, when we were finally able to get to it.
The CEO of that company went to prison, and the company went out of business. Everyone involved knew it was coming. They had a decade to fix things. They needed someone to stand up and say so.
When it comes to your programming career
Sometimes, you just know better than anyone else. With your career, you know best. I have listened to advice on changing my career, but when it came down to the final decision, I had to choose for myself.
“Fintech isn’t going anywhere!”
“Crypto is a fad!”
“Machine learning is too hard to crack!”
I’ve taken my programming focus in askew directions often, and I’ve benefited in some way almost every time. No one else knows all the details of your career and what’s best for it as well as you do.
When being contrarian is bad
To be honest, any time you're a contrarian can be bad. If you haven't at least heard of the concepts in How to Win Friends and Influence People, then the members of your team may shoot your idea down and conveniently forget to add you to the next technical meeting. Here are some specific instances where being contrary was not the way to go.
When you have spent twice as long doing it your own way
I guess the stock market is the analogy of the day. This is like throwing good money after bad. I have done this more times than I would like to mention.
You know how it goes. You figured out this new brilliant way of doing something in code. Four hours later and you're almost done. Two days later and you're almost done. But it would be just so amazing if you accomplish it. You could release your own package and then wait for the stars on Github.
The problem is that the traditional solution would have been done in two hours, and now product owners are asking what's taking so long.
I think it can be super helpful (and fun) to take new and risky programming technologies and techniques for a spin, but this is sometimes best done in hobby time.
When every decision leads to a philosophical discussion (or argument)
Forget the time it takes to squash the bugs of bad code. How about the time wasted it takes to argue about bad code?
Which do you prefer for indentation: spaces or tabs? Yes, you could get into this argument, but really, what does it matter? You can have your IDE transform one indentation type into the other and just move on.
One job I left encouraged this type of discussion instead of solidifying the rules with a linting tool, but I didn't leave because of that. I left because I couldn't get anything done. It was the first job I left because I couldn't move as fast as I knew as I was able. Every code review took like two or three tries depending on who I went to.
By the way, I prefer tabs. Why hit a button four times when you could do it once?
When disagreeing becomes your personality
This has happened to me every time I've been a contrarian. You're still working out why you are being contrarian and it just comes out as anger and curse words followed by the question, "Why is everyone so stupid?"
Not a good start, even if your idea has merit.
Besides turning yourself into a workplace hazard, if your teammates and coworkers start to tag you as someone who is always picking fights, you will begin to lose your bargaining power.
Make it a habit to try to not start with “no.” And when you do arrive to the conclusion that a contrary opinion is called for, limiting your ranting to merely the level that’s called for is the smartest way to go.
If you choose to be a contrarian programmer, you're going to be walking a very fine line. If you don't stand up and say what you have to say, you and your team may run into issues down the road. If you do, you may be wrong and cause a bunch of new issues to crop up. Being a contrarian doesn't mean having a bad attitude about everything. It just requires thought, planning, and tact.
Triplebyte helps engineers find great jobs by assessing their abilities, not by relying on the prestige of their resume credentials. Take our 30 minute multiple-choice coding quiz to connect with your next big opportunity and join our community of 200,000+ engineers.