One of the hardest things in life is to acknowledge our failures. Even harder is to talk about them. If we don’t talk about them … well … they don’t exist. Yet, what we learn from our failures are lessons that stick with us for life. Since I am a grown-up now (not according to my parent of course) I can share one of my biggest fails and what I learned from it.

In my second year of university, I got my first job. I was recruited as a research assistant at the University research laboratory. The laboratory team was led by a brilliant professor and the team was formed by some of the best students in the university. And me. We were working at a CASE tool for the analysis, design, and implementation of software systems using object-oriented technologies. That was my first encounter with an application of such complexity. I felt kind of lost but my teammates were great. One of them become one of my best friends and he mentors me even today.

The hiccup. All good things come with a price. Sometimes it’s big. Sometimes it’s small. Or at least it seems small.  During my year in the laboratory team, I learned a lot of things from my teammates, which was awesome. It started to build my knowledge base which started to build my confidence. Which sadly started to build my ego.

Have you ever noticed that every time a handyman comes to your house the first thing he does is to criticize the work done by whoever was there before? Something similar was happening in our team also. We worked on a very complex application with hundreds of classes. The solution was developed by great students who have been part of the team in the past. So, when somebody worked to fix a bug, instantly that portion of code was crappy, pitiful, and much more. Unfortunately, through the many good things I learned, I got also this small unwanted behavior in my repertoire.

The cold shower. Close to the end of my year there I received a big assignment: to implement a reverse engineering module. Having the trust of our professor to do this was a big deal. The overexcitement resulted in three weeks of intense work, between fourteen and sixteen hours per day. And then the big day has come. As I was presenting the solution, the face of the good professor started to change. The disappointment on his face could be seen from the moon. But he was too nice to say directly that my solution was from another movie. A very bad movie. He explained what was expected. He pointed to some different solutions. And I felt like crap. I felt like I let down the professor and my team big time. I felt like the sky was falling on my head. And suddenly I was thinking how many times in the last year I called somebody else’s code “crappy”.

Easier to destroy … harder to construct. That day our awesome professor taught me much more than how to think to a good solution for the technical problem: he taught me humility and how to be constructive.

When we disassemble a solution, in fact, any solution, there are so many things we don’t know. We might know the context, but we don’t know how a person thought in that context. I bet that in eight out of nine situations if we look back at our code from three months ago we will say: what the hell was I thinking at that time? There is nothing to gain when we dissemble.

What if instead of “destroy and re-build” we just “expand the pool of solutions”? That’s exactly what our professor did. No yelling at me, no critiquing. Just pointing out different alternatives. Identifying problems is easy, providing solutions and alternatives is what makes our life complicated. When we dissemble somebody’s opinions, we put that person in defensive mode. The chances that our alternatives are heard are close to zero. Even if they are brilliant. That’s human nature. If we acknowledge the problem that needs to be solved and we layout the solutions, we have a chance that these solutions are taken into account.

The two lessons I got can be summarised very easy:

• Whenever we find a problem we should lower our ego and think twice before dissembling somebody for that. There are more than enough situations when we are on the other side of the problem.
• Humbleness is the golden key for constructiveness. This key allows our solution to be listened to. It allows us to move from critiques to solvers.

My ego dropped big time that day. Since then I am trying not to destroy a solution to have a door open for my alternatives. I am not succeeding all the time. At the end of the day, I am also human. But this is happening more and more. And sometimes when I’m hearing teams falling into the bad path, I’m just telling the story …