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 the technology. I care about solving difficult 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 that 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 actually 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 are 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
- Believing 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 great 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 (yeap, I witnessed these things 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 realisation that their percentage is growing. And the more I grow up, the more I realise 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 behaviour is very apparent in all sorts of human societies. Having dogmas as life guides makes 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 implementation of a group of people’s thought process who share common goals, ideas and perhaps needs. People around the globe however, don’t share common goals and ideas — 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 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 an 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 completely unprofessional and should raise red flags about any employee / manager / boss, 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 pop corn).
At the end of the day…
Next time someone shows you something new or tries to politely disagree with you about technology, welcome it. Who knows, maybe that someone is actually advancing your career just by wanting to have a discussion with you. And if you happen to find someone who raises the conversation’s decibels beyond acceptable levels instead of giving you utilisable arguments and info, stop the conversation politely. People like these shouldn’t be given the impression that someone actually listens to what they are babbling about. You will be doing yourself a favour.
Software isn’t immune to dogmas. But we, as developers are also no common people. Most of us grew up having 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, bying 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 positively affect our mindset.
In short, we, as developers and as hardcore internet users, should know better than being narrow-minded.