What is the first thing that comes to mind when you hear the word "philosophy"? Probably an image of ancient bearded guys, walking down the beach reading books, writing books, thinking about books, discussing ideas that have nothing to do with the real world.

The whole idea seemed disconnected from reality. People were trying to survive: growing crops, producing food, manufacturing tools, and doing all sorts of practical things. And those guys were walking, talking and thinking about how we got there and where we're headed.

But the first impression is deceptive. Philosophers focused on things that are familiar and that are close to ordinary life, like problems of logic, problems of ethics, social and political constructs. So if you ever catch yourself thinking about these concepts, you can call yourself a philosopher. It's not limited to abstract and metaphysical things. It also covers things that can happen in everyday life and in tech.

Of course, philosophy isn't the first thing that comes to mind when we talk about programming. But if we look a bit deeper, we'll notice that its concepts are relevant for the tech industry too. So it's not a surprise that a lot of people who code take interest in it.

The Definition of Ego

So what is ego-less development? To understand the concept we first need to define ego.

The concept of ego is more complex and multilateral and there are different definitions of what it is. Basically, the ego means self; it is what makes us - us, the driving force that makes us feel special in our own understanding and perspective.

Everyone has a different view on their own "self", the one that fits in their understanding of life and the world.

Another common interpretation of the ego is putting our own interests above others. It's a survival mechanism. Even though we live in a modern world, our basic needs are still driven by this instinct. We need to survive, we need to reproduce, we need to provide. Sometimes it makes us think that we need to take advantage of the others to reach our goals. This kind of ego makes us selfish.

We can also understand ego as an inner critic or our internal feedback mechanism that tells us that we are going great things or bad things.

What unites these interpretations is that ego is focused on the person itself, not on the others. And this can cause problems in different aspects of life, including working in tech.

Problems Caused by Ego

There are several ways that the ego can complicate software development.

Terrible APIs

When an API designer has a lot of knowledge and the knowledge is paired with huge ego, curious things may happen. Using all the fancy design patterns "others should know about" may make the API so complicated noone beside the author would be able to use it. And if they won't use it, they will probably create their own solutions thus duplicating the work.

That's the happy path, at least. Even worse scenario is when the team uses the terrible API in a way that causes bugs. Instead of moving the product forward, everybody is suddenly debugging.

"Not Invented Here" Syndrome

Recreating something that's already there because we know how to do it better. For example, the proliferation of different Linux distributions. Sometimes there are valid reasons to create a new software distribution and sometimes we do it because we disagree with the others and want to live with the consequences of our own choice.

Ego Clashes

When developers try to highlight their own contributions at the cost of teamwork and/or try to protect themselves against the doings of others. It might look like a panic mode and can harm the company, the team, and the product as the problems accumulate.

(Entrenched) Code Ownership

We hear a lot that we should strive for code ownership and developers should be responsible for the code they produce. If a code has an author, then they can make sure that the code is of a good enough quality for a release. That's the good side of code ownership.

But every medal has two sides. The negative side of code ownership manifests in the reluctance to accept a pull request even though it is sensible. It can happen because of personal believes and protectiveness or because the solution is simply novel.

In fact, whenever someone says "We've always done it this way" it's a clear indicator of an ego play, a sign that someone feels insulted and doesn't have a better way to defend themselves.

What Philosophy is All About

You can skip this part if you're only looking for solutions to the problems outlined above. This part is for those interested in different approaches to ego throught the culture.

Let's get back to philosophy for a moment. Nowadays, with the rising popularity of AI and ML, it became more relevant as there are different problems related to ethics.

Stoicism

One of the philosophies I want to mention here is stoicism. Ancient Greek and Romans practiced it. It recently got the second wave of interest thanks to the popularity among many public figures in tech and marketing. They see it as the answer to many of our problems and that it fits our cultural challenges.

In my understanding, the main focus of stoicism is identifying what is and what isn't under my control. Imagine waking up today and seeing that it is cloudy outside. You are asking yourself whether it is going to rain or not, what happens if it does, how frustrated you'd be if it ruins your clothes. There is plenty of overthinking and you focus on the problems.

The stoic approach to this situation would be putting on your waterproof clothes and taking an umbrella. This way you are taking control of the situation.

When it comes to the perception of ego there is also this feeling of being in control.

When someone calls you a poor excuse for an engineer you might feel offended. The natural thing to do would be to fight back, to argue and say "No, I'm not, I know what I'm doing, it's perfectly fine!". That's the loss of control.

Stoics' approach would be to think in different terms. Ask yourself whether it is an immediate danger to our well-being and does it affect our well-being in a long-term perspective. Is it true? Is the person trustworthy? Does this opinion count? Can it hurt our status, our position? Or maybe it hurts the offender even more by showing that this person lost control and we kept our cool.

Stoicism helps us to listen to our ego but question these assumptions within our heads. Identify the real threats from the perceived ones. Is it a tiger in the bushes or is it just a striped rock?

Soli Deo Gloria

There is another philosophical way of thinking that has an interesting approach to the ego. Various Christian thinkers used two similar terms to express it.

Soli Deo Gloria (glory to God alone) which means that we shouldn’t take credit for everything that we do. We are the part of some bigger environment and we should always consider this environment and give the credit due.

For example, I've heard that Johann Sebastian Bach started signing his works with the initials SDG. When he started doing that, his work improved. He was no longer thinking about how he can show his genius to the audience, but how he helps the audience by doing his work.

Jesuits used similar approach with their Ad Maiorem Dei Gloriam (which means for the greater glory of God). And we can see how it works when we look at the process of building a cathedral.

Imagine going back in time a few hundred years and talking to a builder laying bricks on the construction site. We ask them about what you are doing. One builder replies "Oh, don't even ask. I'm laying bricks the whole day in the heat, in the rain, in the wind, in the snow, the work is endless. We'll never finish during my lifetime. People show us no gratitude and are always yelling at us. But I have to do this because I have a family and I need to support them."

Then another says "We are building a cathedral, which is going to be the most spectacular thing you've ever seen. It will be magnificent! I won't live long enough to see it finished but believe me, the future generations will think that we did extraordinary work. I love it."

So what's the difference in these two approaches? The first approach is ego-driven. It revolves around what that person can get from this work. The second approach considers a bigger picture.

Zen

Not forget to mention Buddhism and Zen philosophies and the belief systems of the East in general. In Western culture, people usually like to practice individualism. We believe that we are special, chosen ones to do great things, that is "I" who should be the most important person in the room. In Eastern culture, the focus is more on the collective, on how a person can contribute to the community, their family, their town, their country.

In Buddhism, there is the focus on feeling and being a part of a greater universe. It's not how I can approach things as an individual, but how I can make myself disappear and become a part of the universe.

And the final philosophy worth mentioning is DevOps. DevOps has different meanings and different definitions, but for me, it's something akin to philosophy or to culture, the way we do things.

Look at closing the gap between the client and development, short release cycles, iterative approach to design and reduction of waste. All these things have something in common. They come together because to achieve them we need to build a better communication framework.

We need to be a part of one collective. We can't separate clients and developers. We are building something we can all benefit from. With open communication and shared goals we come to the most important requirement - that we put our ego aside. We have to stop thinking about personal benefits for a moment and think about how we can be more involved and be part of a bigger ecosystem.

How Ego Disrupts DevOps

You know the problems that come with ego, so how they affect the DevOps practitioners?

Inadequate APIs become a source of waste. When you have to look up documentation instead of focusing on more important things, there are more chances to mess things up. And once you've messed it up and the things are in production, the cost of mistakes increases. So APIs should be easy to use and hide the complexities inside, not the other way around.

"Not Invented Here" syndrome is an obvious source of waste. Instead of focusing on delivering a good product, you try to prove somebody else that you are better and more capable.

Ego clashes also present different sources of waste. Everyone on the team focuses on making their part of the job feel more important. That wastes energy and time put into product creation. It may as well lead to decay of a culture, which means problems with efficiency and collaboration.

Entrenched code ownership can lead to "Not Invented Here" syndrome and reduce your bus factor to one. The bus factor is an idea, that illustrates code ownership limitations. How many people have to get hit by a metaphorical bus until there is nobody who knows how your project works? If there is only one person who has all the information and they get hit by a metaphorical bus (which usually means a change of employer), you are left with nothing.

Cultural Tools for Ego-less Development

First of all, you need to create a culture. There are 3 pillars of a strong team culture: safety, vulnerability, and a shared future.

A great culture emerges when people know they are safe, when people share their vulnerabilities, their problems and challenges with each other and when they share some future that they know will get better with time.

Introduce Formal Processes

Unlike bureaucracy, formal processes can help people feel less lost. It should be a logical extension of the culture you are cultivating. You don't need to force it, but there should be a natural progress.

Code Familiarity

Another cultural tool is doing code reviews. People are getting familiar with the code they are producing and everyone knows what's happening beyond the features they are working on.

And pair programming is a good opportunity to leave the ego aside and focus on how to improve the product.

Once everything is familiar and once everyone knows what they are doing, it makes it much easier to work on the product.

Software Tools

I focused on examples in Python because it's the language that is closest to my heart.

Linters (PyLint)

Check your code to see whether it contains any known bugs. If you can see them by reading the code, you can focus on the code quality instead of searching for mistakes.

Code formatters (YAPF, Black)

It takes code and formats it according to the given standard to maintain consistency.

Aux tools (PyAnnotate and MyPy)

They help you create better interfaces, check APIs, and find errors before your clients do.

Git Hooks

You can run it whenever you do an action in GitHub or run them locally. They would check all the tests even before you push the main repository. After that, the continuous integration process would check the changes and finally your peers will get a request for the code review.

Automated Build Scripts (Makefiles)

You can reduce your Continuous Integration/Continuous Delivery pipeline to calling make build, make deploy, make test, make whatever. This way, you can reproduce the same steps on any machine - developer machines, QA machines, CI workers.

Opinionated Frameworks

It's hard to make your team understand why they need to use this opinionated framework instead of a different oneBut once you do, you'll be happy that someone has already made some choices for you and you don’t have to sweat about it.

Behavior-Driven Development

Instead of writing tests to determine if the code behaves correctly, first try to decide with your client what is it that they are trying to achieve with this piece of code. BDD also encourages communication between different stakeholders and brings everyone on board.

Conclusion

These are some of my observations about the ego in play in software development. Where possible I also proposed some solutions and workarounds that could make it easier for the entire teams to own the codebase.

But each of us has probably some ego-related horror stories as well. Share your own in the comments!

Images courtesy of:

Blog

Ego-less Development: The Philosophy of Better Code

Piotr Gaczkowski