Software development is considered a field ruled by logic. Every decision we make is guided by rules that we can follow and understand. Every problem has an engineering solution. Every opinion can be either true or false.
If you’ve spent some time in the software industry you know that this is not true. We make decisions in an ever-changing environment and solving them requires more than pure technical knowledge. The same opinion can be true or false depending on the situation. The most common answer to a question is - “It depends”.
We dive into endless debates on the maturity of technologies, the benefits of different code styles, the best amount of indentation - the list goes on. We still question whether established practices still provide the best value in the current state of software engineering.
At my first job, a colleague gave me a precious piece of advice - to always ask the question “why”. Recently I started a new job and the tech director there told me something similar - to not be afraid to ask as many questions as possible.
I truly cherish working in a field in which everything is questioned because that’s the only way we can uncover the truth. But what does truth actually mean? Can something be true at all? Maybe the answers I get make sense for the problem we are solving but are completely faulted in a different environment.
By continuously asking questions and debating different ideas we actually go into philosophical debates. We aim to uncover the final reason of things - the root cause. Of course, sometimes we just try to persuade the other side to believe the same as us but those conversations are not truly debates.
Sometimes we philosophise about general engineering topics like tabs or spaces. For many of those big picture questions we need to accept an answer for ourselves and form our own reality.
However there are questions which have less of an impact and therefore can be answered more specifically. Question whose truth only affects our company or our team. One of the commonly asked question is “Why is this done this way?”.
We aim to challenge ideas and seek wisdom rather than solve engineering problems. Once the question becomes technical then solving it is easier. Reaching that point is hard.
Instead of trying to find the answers ourselves should we just rely on already established opinions? When is a problem too specific for its solution to be decided by common knowledge?
When asking philosophical questions we aim to challenge the beliefs, thoughts and feelings for a specific topic. So when someone asks about the philosophy of functional programming this is the sort of things they have in mind.
Software engineering is a relatively new field and many truths about it are yet to be formed as a system. But we can’t spend our time arguing about what is right or wrong. In the end of the day we’ll have to make a few hard decisions and do our best to build a good software product.
But how much context, opinions and thoughts do we want to exchange before we do that? This is another difficult question on its own.
This article asks more questions than it gives answers to. I suppose this is the way with every deep discussion. You recursively ask the question “why” until you hit the bottom and the function returns.
What’s Next?
I am writing a series of articles that dele into the philosophical topics of software engineering. I will look at each one from different angles and try to find the root cause behind them. Here are a few examples that I have in the backlog:
- What’s better - tabs or spaces?
- When can technical debt be good?
- What code do we consider clean?
If this is something that you find interesting you can join my newsletter to be notified when a new article gets published.
