First of all, I want to make it clear, I am a relative beginner in the world of development, having come from an 8 year career in IT Support and only just started coding in earnest this past year. I have not worked on repos with 45 billion lines of code, or even something realistic. I have not worked in a true agile team environment yet and I have engaged with and worked with only a few programming paradigms and languages. Take what I say with this in mind.
The Problem
After spending some time on DEV, I have come across a range of posts by people who purport to be experienced developers who have worked on "major projects used by many thousands of people over long periods of time". These articles (which I will not link as I am sure that you have heard these opinions before in this or other places) discuss topics such as programming paradigms (such as Object-Oriented Programming vs Functional Programming) as well as development methodologies (such as Agile) with an emphasis on how bad they are for x reason. I have had similar conversations with people in my own life where I was told for example: "OOP is the Devil because it makes programs too complex in comparison to their purpose"
The discussion
My major issue I have with this kind of conversation is its toxicity to beginners such as myself who are only tangentially aware of the concepts. These kind of opinions are developed over years of working with these concepts and having negative experiences with them such as rampant code over-complexity with OOP or excessive procedural overhead with Agile.
An example of this from my own career in IT Support is that I personally do not think that ITIL is a particularly good framework out of the box for small to medium service teams. In my experience, I believe that it can prevent tasks from flowing to the correct people on the service team at the time that it is needed and cause significant delays in properly designing and scaling smaller support teams. I have come to this conclusion over years of working in small to medium teams where this structure often hindered rather than helped.
While this is my opinion based on my experience, it is wrong of me to say that this is the truth. Importantly, I may have also arrived at this opinion because the organisation I was working with were not properly implementing the ITIL guidelines or the tools that I was working with were not setup correctly to properly adhere to the ITIL framework. My opinion could conceivably be formed based on bad experiences I have had in my professional life.
Opinions like this are strongly influenced by the professional experience of the person sharing it as well as how they think. Programming paradigms, development philosophies and other meta topics such as these serve first and foremost, as mental models for compartmentalising and abstracting highly complex and deep topics both within code and the real world. What works for one person might not (and in some cases, will not) work for everyone.
In the example I provided above, it is not up to me to decide of someone else should like ITIL or not. The beginner should under all circumstances, be allowed to form their own opinion without the opinion of the teacher. It is highly disingenuous and in some cases harmful to teach someone that "x is bad" when they do not have the tools or experience to properly assess the opinion let alone form an informed opinion of their own. I am also self-aware enough to know that my opinion about ITIL is generally not shared by the majority of organisations in the industry and some people could view it as just wrong.
Conclusion
To be clear, I am not suggesting that the experience of the teacher should not be communicated, just contextualised. Highlighting the pitfalls of a specific methodology and explaining why you believe it is the wrong choice for a specific situation can be significantly more valuable than stating that something is bad outright because it "always produces an undesirable outcome".
As a relative beginner at all of this, after reading or hearing: "OOP is bad and you should never use it because it always turns into unmaintainable spaghetti code at scale," it kills my motivation to learn as I feel as if my efforts, short as they may be have been, are going to waste. This is just not helpful, even in the instance that it is true.
Fellow beginners: do not listen to these people! Do not let them push their negative professional experiences onto you. Form your own opinions from your own experience.
I would also speculate that if I dedicated a decade to learning and implementing OOP for example, having some 25+ year veteran come and tell me that my decade of experience is pretty much worthless because OOP is bad would certainly rub me the wrong way.
Veterans: it is okay for you to have these blanket opinions but please, wait until we ask you to express them to us. Often, your opinion does more harm than good especially if we don't fully understand the context or have the experience required to properly understand why you are saying these things.
Thank you all for reading! I would love to hear your take on these kinds of entrenched toxic opinions. Do you agree or disagree?
Top comments (5)
I agree! Sometimes people tend to state their opinion as the truth, leaving no room for other perspectives. I sometimes mention in those situations that I respect their experience, but I also want to have the chance to gain my own experience so I learn why I am choosing something from experience and not just from someone else's opinion. Most of the time they perfectly understand :).
At a more meta-level, the whole "x is bad" is a symptom of whatever platform you're reading the article on.
Making hard-hitting opinion pieces that trigger potential flame wars usually creates increased engagement. AKA click-bait works, or at least less direct click-bait and more "subtle" kinds do work.
So even as a reader, understand that you are being "influenced" even before you click on an article. What you see is not the "truth", it's a subjectively selected and curated list of things that was designed to keep you engaged. Those subjectively selected articles are subjectively written to get that engagement. And finally you'll subjectively view them how you see fit when you read them.
No-where in here is some "ultimate truth". A 20 year veteran has seen a lot, but can still be dead wrong, or have their own opinion on a subjective topic, but its ultimately up to the read to read and determine their own viewpoint on the topic. Just keep in mind what you read is in itself, not objective.
I fully agree and clickbait does work and to be honest, I suspect that my authoring of this post is just a boiling over of frustration at reading or hearing this kind of thing. I've definitely had conversations like this with people in the real world that just leaves me confused. I often ask these people, how can so many segments of the industry build so many successful things and yet be so wrong about how to do it?
Thanks for the comment Brad! :)
As a 40 year veteran I believe that any paradigm can be good or bad, and any language can be poorly or well written. As you say, we need mental models to solve problems and it is probably natural that we are more productive using models we know implicitly - however the world changes and no two challenges are the same, so it's our job to react (no pun intended). I've built commercial products in everything from Z80 assembly language, via C++ to C#, JavaScript and TypeScript - so I've needed to constantly challenge my thinking and we should all try to do that.
Now I can have opinions, which are just that, for example I'd avoid bothering to type all those extra letters in TypeScript because I don't find them very useful - clearly lots of people do and I understand why. I would happily debate someone about that, but I'd hate that to be anything more than an informative view of reality.
Software development, framework, language choice and paradigms can become matters of faith. Personally I think we always have to listen. Clickbait is a problem, with those 40 years under my belt I can mostly notice it (but not always!) There are many authors I read whose opinion and arguments I appreciate even though I don't do what they suggest and believe that I have a fundamentally sound model which is different to theirs. I also know in 10 years time I'll have a different one :)
Our work is to make things, not write beautiful language. The things we make will often live beyond the time we work for an employer so we should be respectful to those who come after us and make our things in the clearest and most comprehensible way possible. We frequently are doing more than changing the tyres on a car, we are inventing new types of car! If you look at how complex cars have become in the last 20 years, then we must understand that all revolutionary technology must be inherently complex, so we have to balance the resources available to build code and their experience with the objectives in mind. Race to the bottom development will be replaced by AI long before complex system design and the imagination to understand what should be built.
Thanks for the comment Mike, it is highly appreciated and quite insightful!