Passion is what drives engineers
People land in the software engineering world for many reasons. Passion for technology is almost always on that list. Technology changes constantly, and coders have to learn new languages, frameworks, libraries, tools, and methodologies, consistently throughout their careers. The energy that pushed engineers to learn throughout their careers is fueled by the same passion they felt when they first chose to join software development.
If you are a coder, you most likely know what I am talking about. Remember that feeling of discovery and wonder for a new language, algorithm, solution, or concept? Remember the sense of enlightenment when something all in a sudden went from obscure to making sense? If you have been in the industry even a few months, you most likely had that magical feeling many times over.
During your learning journey, you eventually tend to form strong opinions or likes and dislikes for technologies, ideas, or models. This tendency originates in different ways at different times. For example, it happens when one of your discoveries is more exciting than usual, and for some reason, a particular aspect of what you learned hits you at a deep level. Or perhaps you have worked for a company for a long time, and you have used the same technology for years; that technology becomes very familiar to you, it becomes your tool of choice, and you start identifying yourself with it. The more time you spend with it, the more invested you become in it, and the more uses you find for it.
Passion can mutate into a dogma
Becoming an expert in a technology is a good thing, but you need to watch out for the inevitable formation of dogmas. A dogma can take many shapes, and usually forms over time. For example, people who are passionate about Ruby go from “knowing Ruby”, to “using Ruby”, to being “Ruby experts”, and finally they call themselves “Rubyists”, not necessarily in that order. Once a developer claims to be a Rubyist, they tend to identify themselves as someone who loves Ruby, and a dogma of Ruby being the right language for all projects starts creeping in the picture. Once a dogma has taken place, it is difficult to eradicate. A “Rubyist” is often someone who thinks that Ruby is the only technology you need to master. Those developers will go out of their way to find problems that they can resolve with Ruby, just because they can be resolved with Ruby; a classic case of a tool in search of a problem.
Dogmas are a form of assumption
A dogma is a form of assumption, and you know how I feel about assumptions from my earlier posts. To go along with someone who has dogmas is difficult unless you share the same dogma. Teamwork becomes difficult when dogmas pervade the team and so is getting and keeping a job because you tend to clash blindly with others.
In my mind, there is no place for dogmas in the software industry. There are no answers that are always right, and there should be no technology applicable to all problems without a healthy “it depends”. In tech almost everything is situational, and dogmas prevent the right questions to emerge. Without the right questions, you can’t come up with the right answers.
When people are dogmatic, teamwork is difficult
Dogmatic team members who share the same ideas might seem well aligned, but there is a danger lurking behind that pretty picture. A team with ideas aligned based on shared assumptions is blind to new realities and a shifting context. Alignment can be dangerous when it is the product of a non-diverse group of people stuck in their ideas. We see this every day in politics and other groups of like-minded thinkers. That is why many people vote the way their parents used to vote, even if the context shifted completely during the last generation. In general, a team formed by people stuck in their preconceived notions is a team that inhibits innovation and slows down change.
In software development there are many common areas where crystallized and unmovable opinions are often applied too broadly to everything at hand, causing blind stances to become stronger than good judgment. Some examples are TDD, languages, frameworks, development processes, documentation standards, coding styles, methods of approaching certain classes of problems, etc.
There are many types of dogmas
Sometimes dogmas are generational and are due to the ideas that were popular when the engineer started coding. Other times dogmas are due to character traits of the engineer. Peers or mentors preferences also tend to infuse dogmas. In any case as the context shifts, the validity of rigid ideas tend to lose grip with reality.
Dogmas come in many flavors. For example, they can be positive or negative. A positive dogma results in always choosing the same thing, over and over, despite the context. A negative dogma results in not choosing something even if all evidence points to the fact that it would be a good idea to choose it. While everyone tends to form preferences and opinions, dogmas are blind and not movable.
Dogmas can stop you from landing jobs
From a career standpoint, dogmas will prevent you from being able to land many jobs. I have interviewed countless people who claimed that one particular method, technology, language, framework, or idea was the best thing to resolve any problem, even without knowing what the problem was. Good judgment and flexibility to adapt to a team are key ingredients for a successful career in tech.
The best solutions to technical problems depend on the company, the environment, the business, the existing technology, and many other contextual and situational factors. You should expect that when you move from one job to another, many of the decisions that were valid in the last job won’t work in the new one. Unmovable points of view formed in past jobs limit the ability to learn and make career strides.
You are probably blind to your own dogmas
The sneaky reality of the problem is that dogmatic people often do not know that they are dogmatic. Things make sense in their mind, and they are very comfortable with their unmovable ideas. They hear other points of view and dismiss them quickly based on preconceived notions.
To close, I recommend the following guidelines to avoid falling into the “unhireable dogmatic individual category”:
- Periodically question everything, especially when there is a shift in context.
- Surround yourself with a diverse group of people who you feel are smarter than you.
Try being vigilant to phrases like “that is how we do it here”. Best practices are good, but dogmatic positions are not.
- When you start doubting a stance you use to hold, reassess it immediately.
- Listening to your instinct will guide you well.
- Do not think in absolutes.
- When someone is unmovable in a stance, question and analyze the reasons for it. Is it a character issue? Or is do they have a point you are not seeing? Do not assume they are wrong. They might be right, and you might be wrong; however, question both possibilities. Usually, the truth is somewhere in the middle.
- Do not hire people who have absolute dogmatic stances on things. Base opinions on information, not on assumptions.