Stay objective. Keep experimenting.
We’ve all seen articles that take things a little too far.
I wanted to focus on the extremes in tech articles and share my experience in questioning the rationales behind them. Specifically, ones advocating for the wholesale destruction of popular frameworks, libraries, design principles, or languages.
My goal in this piece is to give you some example questions to ask about the author’s reasoning. If you are a new developer and find articles with extreme positions hard to understand, or are not sure what to believe, these can help you arrive at a conclusion that makes sense to you.
I believe extreme measures should be backed up by iron-clad rationales. It’s not up to me to tell you whether an author is right or wrong. Learning to question the rationale of other developers and coming to your own conclusions is an important skill.
For the rest of this article, I’ll go over three common rationales I see. I will focus on rationals I believe to be written in good faith. Clickbait is not included on this list. I probably should, but I struggle to find questions that can rationalize it.
The topic for the reasons will be represented with the letter X. You can substitute X with anything pertaining to the type of software you use. As a web developer, I would substitute X with things like React, React hooks, OOP, or Node. Those are the most popular topics I see people writing against.
After the rationale, I’ll include questions you can ask yourself before deciding what route to take. These are the kinds of questions I ask myself when reading.
The decision to act, in the end, is down to you.
Rationale: X is poorly crafted and makes your code base worse. It does not achieve what the developers set out to accomplish. It actively makes developers worse and reinforces bad practices. X is only popular because of hype, not quality. X has very few redeeming qualities. When people are honest about the flaws in X, it becomes obvious we should be using something else.
Ask yourself: Does the author have a comprehensive grasp of how X works? Is their implementation in line with what the creators intended? What do other professionals say about it? If X is as poorly crafted as the author would have you believe, why have so many talented professionals adopted it into their own code base? Is it possible everyone else is wrong, and they’re right? Or did they miss something along the way?
Rationale: The author was tasked with building something at their job, chose X for the implementation, the project failed, and they got fired. They go on not so indirectly to blame X for the bad outcome. If only it had been better suited for what they were trying to accomplish, had better documentation, or had fewer bugs, they would still have a job.
Ask yourself: Is it really X that got them fired? Or did they pick the wrong tool for the job? Is the author’s frustration clouding their judgment? How much sense does this reasoning make when applied somewhere else? If I use paint thinner to water a houseplant, and the houseplant dies, is the paint thinner to blame?
Rationale: The author has discovered Y and had a great outcome with it. The outcome was so good they wanted everyone to try it and forget X. The shortcomings of X do not exist in Y. X is old and should be confided to the dust bins of history. The future is here, and it’s Y.
Ask yourself: Does something being old mean it has no value? Is it possible that Y is great and worth trying, but also, X still has a lot to offer? Could the author be getting carried away with their enthusiasm? When was the last time you got something new and all your old stuff seemed dull?
The purpose of this piece is not to disparage authors who take extreme positions. Most of the time, they have good points in their work. My goal is to give you the tools needed to not get swept up in their extreme language.
I hope you can learn how to ingest the parts of these articles you agree with while being able to not be swayed by the parts you don’t agree with. Good media literacy will always be a valuable asset for developers.