Dogmatism and Software Engineering should be an oxymoron
Thoughts on the strong feelings about Technology that lead to Software Dogmatism in the workplace.
I love coding. I don’t care about the language I use or technology. I care about solving challenging problems, about creating something from nothing.
I grew up believing that software is philosophy, knowledge, way of thinking. I still do. However, I have to admit that based on the things I have seen since I started working in the industry, I believe that more often than not, we stumble across stubborn people that get grumpy when technical decisions are not what they agree with. That happens many times without having the exact technical knowledge to back their opinion. That’s what I call Software Dogmatism.
For the past few years, not a single day has passed without learning something new and without actually coding (except some notable exceptions where I was taking a vacation near the sea). If I’m not developing software for my clients/bosses, I will do it for myself in any programming language that I can find. I love reading about modern software engineering concepts, too. I am very proud of the speed with which I can grasp new technologies. I adore it. This skill, however, has come after many years of forcing myself to get out of my comfort zone every time I touch a keyboard and by trying to keep my mind open regarding anything new that emerges in the software world.
Not everyone shares the same thoughts with me, however. Growing up in this industry, I sometimes found myself coping more with dogmatism than with software problems and their solutions to a point where it bothers me. Here is some example of situations where Software Dogmatism is prominent.
- Believing that your programming language of preference is better than the rest (wtf!), because… it’s the only one you know
- Assuming that your platform of choice is better because… it’s the thing that keeps you fed or because your friends are using it.
- Bashing people using a tech different than what you use because it may mean that someday you may have to learn how to use this tech too.
- Not having ownership of the code one writes (the grand notion of “it works, therefore it’s enough” — leading to all sorts of hidden bugs and non-scalable code) because no one took the time of actually questioning oneself.
I first grasped the concept of the “confidently wrong programmer” by reading Deon Thomas’ excellent article “A Good Programmer: Why You Need to Avoid Being One”. Quoting a colleague of his:
They [confidently wrong programmers] tend to be dogmatic, intolerant and impractical. In our line of business, that can result in inappropriate and self-defeating design decision
Ringing a bell? I’m sure it does. Possibly this description fits one of your colleagues, or even yours. I would stretch the quote a bit further: The confidently wrong programmers, if left unchecked, can lead to an entire team losing their morale or be dismantled. I have witnessed this thing happening once or twice.
Sometimes I feel that this kind of developer is the norm and not the exception (hint — fortunately they are the exception), but what strikes me most of the time is the realization that their percentage is growing. And the more I grow up, the more I realize that dogmatism doesn’t solely plague the software world but the entire world in general.
Let’s take a brief look over some discussions I had during the last few years that triggered some fierce arguments that elevated my blood pressure a bit more than usual. What is astounding in all situations is that no one thought of actually saying something like, “hey, why not learn both? Why do we have to choose?”.
- iOS vs. Android (why not do both?)
- React vs. Angular (why not learn both and use each one as appropriate?)
- Native vs. Hybrid (why not do both?)
- C++ vs. Java (seriously? A language war? Why not use both?)
- … etc. etc. etc
This kind of behavior is very apparent in all sorts of human societies. Having dogmas as life guides make it easier for individuals to feel that the foundations of their existence are simple, straightforward, and well established. It also facilitates interactions with people having the same views. For many, it is a social enabler. However, it is also the root of many types of problems like cultural wars and social breakdowns (I believe that no explanatory links are needed here).
That’s the beauty (and also the curse) of it. Programming languages and technologies are the implementations of a group of people’s thought processes who share common goals, ideas, and perhaps needs. People around the globe, however, don’t share common goals and plans — on the contrary, different climates, needs, and cultures generate/force different thought processes, many times incompatible with the current software status quo. It is then when another group of people take the initiative and rethink existing approaches to solve common problems, in the hopes that they will better fit the needs of as much as large groups of other developers as possible. Software is the only profession in the world in which this phenomenon is so apparent and so easy to be a part of.
The Science of Software was founded on these exact values, and the industry has already decided that this is the way to move forward regarding the adoption of future concepts.
What eludes me is the reason why many people I have encountered feel that the Unknown in Software (whether this is a new tech, the return of old tech, etc.) should be treated with fear, doubt, and dismissal at first sight. I still haven’t figured out why instead of communicating with each other and share knowledge while trying to (elegantly!) draw the attention of a fellow developer to take a look at the ecosystem we program in, we feel it’s better to (just an example) just bash a technology entirely until there is no one left to argue with. Not only this type of approaching Software is entirely unprofessional and should raise red flags about any employee/manager/ boss, but it is also sometimes insulting towards fellow developers. No one has ever gained anything from arguing like a grunt (except maybe people standing aside, watching shows like that while eating popcorn).
At the end of the day…
Next time someone shows you something new or tries to disagree with you about technology politely, welcome it. Who knows, maybe that someone is advancing your career just by wanting to discuss it with you. And if you happen to find someone who raises the conversation’s decibels beyond acceptable levels instead of giving you utilizable arguments and info, stop the conversation politely. People like these shouldn’t be given the impression that someone listens to what they are babbling about. You will be doing yourself a favor.
Software isn’t immune to dogmas. But we, as developers, are also no ordinary people. Most of us grew up having the Internet in our homes, and we already knew better than most about its fallacies. I remember that a few years ago, we used to communicate with people around the globe in forums and chats, buying books from Amazon because the one we needed wasn’t translated, etc. That brought us in contact with all sorts of developers and tech enthusiasts from around the globe. Each one of them had something different to offer the industry. That ought to be enough to affect our mindset positively.
In short, we, as developers and as hardcore internet users, should know better than being narrow-minded.