When You Don’t Have an Opinion | CS Pep Talk 002

To the student who feels like their opinionated classmates know way more than they do:

“Okay, Visual Studio? Way better IDE than Eclipse.”

A furrowed brow. “Okay… uh, what about IntelliJ?”

“Eh,” a pause, “IntelliJ’s okay; but VS’s Intelli-Sense is honestly superior.”

What even is that? And I like IntelliJ just fine!

If you understand that conversation, you know vouching for VS over Eclipse or IntelliJ is… frankly, a pretty dumb hill to die on. (Not that you can’t prefer it over another IDE! It does have good Intelli-Sense/that auto-complete function feature.) But unless there’s like, one specific feature you need for your work that’s only in VS, it’s not something you should reasonably go kicking and screaming over.

Unfortunately–and this is something I encounter a lot in undergrads who are just a bit overconfident–conversations like this where someone is way over-opinionated about something tend to happen from time to time; and I remember when, back in my freshman year, stuff like this would really intimidate me. Am I supposed to know all this stuff? Should I have a strong opinion like that?

If I’m being honest, I still feel intimidated sometimes. As I’m writing this, I’m at the end of my sophomore year*, now with two new languages under my belt–C++ and Scala–on top of ones I’ve worked in before–mainly Java and Kotlin–and… while some of my classmates are comparing language pros and cons regularly, I still couldn’t tell you all of the nuances, benefits, or consequences about each language, at least not to the extent other are. C++ has pointers, Scala has Options and lots of lambda functionality, Java’s compiler is infinitely more helpful for debugging than C++’s… but that’s all pretty basic stuff. I realize, though, that for beginners, even little details like that are concepts you’re just not familiar with yet. But hold on to that key word: yet!

One of the things a lot of people find exciting about coding is that, at first, it seems like there’s a right answer and a wrong answer. Your code either works or it doesn’t, and if you find the things that don’t work, you fix them and then it does. It’s like a puzzle – that’s how I describe it when people ask me why I love programming!

But then, one of the things you start to learn as you progress is that… there’s not generally one “right” answer, and there’s a bajillion ways for it to work and still get it ‘wrong’, too. Classmates start explaining ways they did the homework and you think, “wait… I didn’t do anything like that,” or you realize halfway through your implementation that your solution isn’t going to catch a certain edge case and now you’re back at square one, or… you get the point. This is where I hit my first slump, or period of frustration where I could see there were better ways to code things, but my own ability to code them wasn’t quite there yet.

See this graph from artist Marc Dalessio – you can replace “Improvement in Painting” with “Improvement in [just about any sort of technical skill]” and it works just the same. You start to improve, think you’re doing great, then realize how much you have to improve, grow frustrated, work hard, then start to improve again.

marc graph
http://www.marcdalessio.com/self-portraits-over-the-years-2/

All this to say: as your ability to see better solutions increases, so will your ability to determine what makes them better and why – and this is when you start to develop your own opinions about things. You need to understand how hashmaps work before you can explain why you think they’re a better or worse solution; you need to have worked in multiple IDEs for a little while before you can reasonably explain why you prefer one over the other; and you need to be patient with yourself as you’re growing. Don’t let opinionated people make you feel like you’re capable of less for not having an opinion.

Since knowing more generally results in having more opinions, people tend to think that having more opinions automatically means they know more; but that’s simply not the case.

Humans like to feel like they know a lot. Your classmates and co-workers are no exception. The people who are being loud are likely looking for validation of their own knowledge or intelligence; the people who give their opinions condescendingly are pretty much always trying to boost their own feelings of superiority or capability. The right kind of opinion-sharing should be framed like a piece of advice or a teaching moment, not a cry for attention from the sharer.

There are times when having an opinion is important or perhaps expected, like if you’re at an interview and need to explain when you’d want to sacrifice time complexity over space complexity, but most of the time, you don’t need to have explicit preferences – especially when you’re still learning. I’ve learned that “I don’t have enough experience with that yet to say,” is a perfectly valid answer; so is “I think I prefer that one, but I couldn’t tell you why.” And for things like actual code, where there can be objectively better or worse implementations, that’s just another part of the learning process – if you don’t get why one way is better than the other, you’ll get there in time. That’s just an experience thing.

So the next time you hear someone preaching the glories of VS Code, or criticizing someone’s choice of language, or telling you that light themes are the worst… relax. You’re not a worse programmer for not getting it all yet. Opinions will develop with time – or maybe they won’t, and that guy who really likes VS Code just… really likes VS Code. You go, dude.

(But if we’re being honest, if you’re using a light theme… please, man. Repent. Embrace the darkness.)

* small but important disclaimer: I know I’m not far enough along to be making some of the claims about the workplace that I do; any and all claims I make about the industry have been double-checked by people who’ve worked in SWE for a long while.