Note: this page is part of the “Essays on Software Engineering”

I often encounter and work with people who believe they are inventing the wheel and are so unique that you need to to listen to them and do exactly what they say (in French, you would say “ils pensent avoir inventé le fil à couper le beurre”).

Such people take themselves too seriously. They believe that without them, the world would not go round. They will try to block you for the sake of being right when in fact, all what they are is annoying. Do not be such a person. They are full of themselves. And very boring. Life is not made to be boring. You are better than this.

The academic world is full of such people, frustrated that they did not find what their fellow neighbor invented and believe a solution cannot be good unless they invent it. Many researchers are so frustrated that they just reject others work, copy it, or tweak it slightly to finally claim a new invention. There is even a name for it: Not Invented Here.

Of course, the very same behavior is present in the corporate world. Remember that coworker who criticizes other projects because it was led by their peers? Or the grumpy developer who re-implemented a piece of code just because he does not like some obscure (and often, very subjective) aspect? Would the reaction be the same if it was done by them?

Remember how different teams duplicate work inside the same companies instead of having shared code they can reuse? Or programmers not removing their old deprecated code (aka dead code) “just in case” it might be useful?

Duplicate efforts can be useful sometimes. For example, when creating the iPhone, Jobs had two teams: one implementing the phone using software, the other using hardware. In this exact case, the objective was to compare two ways of doing one thing (we all know the result: the software variation won). But the vast majority of times, duplicating work is an ego issue, with people thinking they are better than <insert-name-or-thing-here>.

Do not be driven by your ego. This does not help you to move forward and is mentally draining. This also does not help people around you.

Instead, be driven by objective goals and metrics. If there is an objective to improve quality of a particular piece of code, do not write a new project: contribute to the existing one and improve its code coverage (remember that re-writing projects from scratch rarely works).

I believe there are two powerful principles to follow:

  1. Be mindful of others.
  2. Do not take yourself too seriously.

The first principle is basic and yet, often overlooked. Try to put yourself in other people’s shoes and understand how they feel. That will help you empathize with the difficulties they might be having. This often explains why or how they react to a particular person or event. This principle is also illustrated by the habit “Seek to understand, then to be understood” in The 7 habits of Highly Effective People, an amazing book I would recommend.

The second principle is useful to put things in perspectives. You are a human being who is failable by definition. You probably believe you are smart and better than others because your mom, wife or dog told you. In fact, as suggested by the Dunning Kruger effect, you are probably the worst person to know your own personal value. This fact is illustrated every day in the stock market: many gamblers investors believe they can beat the market when in reality, all they really achieve are losses. Similarly, many engineers believe they know how to optimize code themselves manually when in reality, the compiler does it better with optimization heuristics that have been implemented by researchers and language specialists. You might like to think you are better than others but you are probably not. Entertaining the idea of being that smart is counter-productive and is not going to help you.

You will make mistakes and this is going to be okay. Your challenge is not to not make mistakes: you will do bad things sometimes, regardless how hard you try not to. Your challenge is to put mechanisms and processes that will help you to avoid mistakes so that you catch them before you commit them. In software, this is done by using defensive programming, increasing test coverage (unit/integration tests), and having good observability/monitoring.

We do not succeed because we are better than others. We succeed because we understand how to be successful with them.

So get back to work, be nice and do not take yourself too seriously.

Note: Thanks to Najwa for editing. 🙏