Good and Bad Times as a Contrarian Programmer

When I think of the traditional leaders in tech, I realize almost all of them were contrarians. I see Steve Jobs telling everyone to “Think different” as long as they did that thinking with an Apple product. I see Bill Gates doing a lot of unconventional things to get Microsoft off the ground. I see just about everything that Elon Musk does.

But, just like the people you hear that strike it big trading stocks, there is survivorship bias at play. For every contrarian success story that you hear about, there are probably 100s of failure stories that didn’t make the news, because who wants to read about that.

In my programming career, there have been a few times when being contrarian was good and just as many times where I should have kept my mouth shut.

When being contrarian is good

There is more to being contrarian than saying “that sucks”. So while there are good times to be contrarian, there are also about 100 bad ways to present your case to every good one. Tact is just as, if not more important, than your suggestion.

When you have had experience with the technology being suggested

I can remember multiple times where I voiced my opinion and didn’t push the issue when I should have. One was when the business decided on a payment processor, who shall remain nameless.

If you worked in ecommerce about a decade ago, you can probably guess who I am talking about. They were one of the few options back then, and they are still around today. Guess what. Not much about the service has changed.

Stripe would have been perfect for what needed. We needed payment processing that would work well with React. Well, the business’ choice did not. We even had to fork the React component they suggested to add the functionality it needed. So it took about two weeks to add a simple payment form that could have taken hours.

When you spend twice as long on bug fixes as you do adding features

Sometimes it is good to let old software die. I have 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 days to fix some things that seemed like simple bugs. But we had to add features to comply with the law. Those took days too, when we could get to them.

The CEO of that company went to prison, and the company went out of business. They knew it was coming. They had a decade to fix things. They needed someone to stand up and say so.

When you know where you are going

Sometimes you just know better than anyone else. With your career, you know best. I have taken advice on changing my career, but when it came down to the final decision, I had to choose for myself. No one else knows all the details of your life as well as you do.

When being contrarian is bad

To tell you the truth, any time you are 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 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. 2 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 is taking so long.

When every decision creates a philosophical discussion/argument

So which do you prefer for indentation, spaces or tabs? That should shake loose this type of disagreement. 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 2 or 3 tries depending on who I went to.

By the way, I prefer tabs. Why hit a button 4 times when you could do it once?

When you’re on a rant and you don’t notice your manager enter the room

For me, every instance I have been contrarian had this stage. You are still working out why you are being contrarian and it just comes out as anger and curse words and “why is everyone so stupid”.

Not a good start, even if your idea has merit. You just threw that out the window if someone overhears you in the rant stage. It is good to rant sometimes and it may lead to a solution, but find a place where no one can hear you.

Conclusion

If you choose to be a contrarian programmer, you are walking a 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 different issues. Being contrarian doesn’t mean having a bad attitude about everything. It requires thought, planning, and tact.


Stephan Miller

Written by

Kansas City Software Engineer and Author

Twitter | Github | LinkedIn

Updated