Learning

Secondhand Knowledge

Mak Arnautovic on Dec 30, 2016

"AngularJS is terrible! I cannot understand why anybody in their right mind would choose to do anything with Angular."

"Oh, yeah?"

"Yeah. It's unbelievable how bad it is. It's unintuitive, it's slow, the documentation is garbage, it takes forever to write, and it's on its way out the door—there are too many actually useful frameworks on the horizon. All you've heard about Angular is hype."

"People seem to like it?"

"They're all idiots. Every single one of them. There is zero value to writing something with Angular. Did you hear what happened with version 2?"

"No, what?"

"It's not backwards compatible with version 1! Meaning if you want to update to the latest version, you're SOL because all the code you've written up until then won't work ever again."

"Wow that seems silly."

"I'm telling you, it's completely stupid. Never do anything in Angular or you're just wasting your time. Like, it's not hard. When you want to build a framework, make people's lives easier…not more difficult. I don't know what the developers were thinking when they designed this disaster of a framework."

"Yeah, seriously that sounds awful."

"It really is, I'm telling you. But to be honest, JavaScript itself is horrible too. I cannot understand why in 30 years nobody has come up with a good alternative. I might do it myself since nobody seems to care enough."

"What do you like?"

"Clojure is cool. I've just started playing with Haskell and it's really cool as well. They are functional."

"What's cool about Clojure?"

"Distributed systems. Clojure is insanely fast and enables you to do heavy computation across multiple servers and stuff. It's baller."

"What about Ruby?"

"Ruby is fine to start out with, but it's beginner stuff. Once you're familiar with how to code there's no reason to stay with it. It's slow compared to other languages, therefore not as good."

I see conversations like this all the time. At one point or another I've played the role of either side, the wide-eyed newbie and the expert. Only, as I'm sure you can tell by the lack of detail and accuracy of concerns, the jaded expert isn't an expert at all. In fact, the person doing all of the complaining hasn't ever written an app or worked on a project in any of the languages they've complained about. To someone with experience this may be obvious, but to a beginner they seem knowledgable and passionate enough to be credible. The beginner in this case can have a few weeks of experience learning the fundamentals of Ruby, while the expert has a few months of experience and a few CRUD apps under their belt. There is, of course, nothing wrong with that level of experience; we all had to start somewhere. In the grand scheme of things, though, the senior here is really still in the budding stages of beginner status. Something you don't often get taught by this point in your career as a programmer is that as the highest-ranking developer in a room you've got certain responsibilities when it comes to sharing knowledge. We're taught that we have a responsibility to share, but we're not necessarily taught that about the repercussions that come with sharing certain things.

We, for some reason, take the tools we use very personally and like to rag on the ones we don't like. There was a talk done by one of the team members at DNSimple discussing this phenomenon, called programming psychosis. That's for another discussion. What I'd like to talk about today are the side effects that these heated arguments can bring. The above expert didn't just pull the things they are saying out of thin air, they likely pieced that opinion together from various sources. Books, articles, and blog posts are one outlet… but the biggest one tends to be speaking with, or listening to, developers senior to them. This can be a superior at work, an instructor, a mentor, or a speaker. As developers we live and die by logic, and it's easy to follow the logic behind formulating an opinion such as this one.

"Well, I've never written Java code. But my teacher, who has been developing software for 15 years told me all of these horrible things about it. Teach knows what (s)he's talking about, therefore instead of taking the time to discover any of this myself, I can just call super and inherit the knowledge."

In some cases, that works. It's why we have conferences, it's why we talk about code with our friends and co-workers. But the earlier on you are in your career, the easier it is to forget to not believe everything you hear. Or at the very least, to take it with a grain of salt. For example, yes, Java being statically typed can seem annoying to a career Rubyist. They can tell you in 60 different ways why dynamically typed languages are better. Strangely, they sometimes forget to find a single way to tell you about the benefits of statically typed languages. What you're not hearing in the epic rant about "Ruby > Java" is that dynamically typed languages have only worked better for this person until this point because the types of projects they've worked on are best suited for dynamically typed languages. They can have 30 years of experience as a developer, but that doesn't mean they have 30 years of experience working in different fields, on multiple kinds of projects, or different kinds of development. Furthermore, it's more fun to complain than it is to praise. Angry rants are funny and engaging, positive infosessions feel like school. For every five angry rants about Java, you'll only hear one (if that) discussion about the many positives of the language (or the counter-argument to the "negative" aspects of it).

My goal isn't to say to not listen to your mentor, your boss, your teacher, or your friends. My goal is to say that what you hear should be used as a starting point for your research to come to your own conclusions, not as something to adopt as your own belief. Though it might seem like the work has already been done for you and that starting from the beginning is a waste of time, you're not doing anyone any favors by regurgitating the bits and pieces you've picked up on over the years back into the community. You're always going to be more experienced than someone, and less experienced than someone else. If you're sharing (dis)information based on an opinion you heard from someone above you, there's no reason to think that just because they have more experience they're not doing the exact same thing. They will of course be able to provide more detail than you would if you were talking out of your ass, because if they have more experience developing… they have more experience compiling their second-hand knowledge as well. The only way you'll ever know for sure is if you see them in a conversation with an actual expert on the subject at hand. It's a one-way street, it's impossible for the river of bullshit to flow in the opposite direction.

Our industry thrives when we share information, discovery, and knowledge. It's one of the most beautiful things about our communities. I hope it continues for years and years, and perhaps coming to this realization is simply something that comes with growing as a developer. It took me a long time to get to the point where I realized that I shouldn't just rehash what I've been told by people I respect. It actually took a lot of embarrassment to get to that point. I, like many others do, was concious of what I was doing by following the logic from above. What took me a while is to gain a sense of perspective, which is all-important. Ask questions, listen to the answers, and study the trade-offs. You don't need to have 10 years of experience in Angular to rag on it, but you do need an opinion you took the time and effort to craft yourself, from your own experiences. If you wouldn't say the things you want to say about a particular technology to an expert in the field, maybe don't say it to a beginner either.

Share on Twitter and Facebook