Why is it important to know how to fail/lose

DateTime.AfterPost - DateTime.Now = 3 minutes

As you’ve already know, I’m originally from Argentina and proud of that! Born and Raised there ‘till I was a teen.

One of the most (if not the most) famous card game in Argentina is called “Truco” (“Trick” in Spanish). It’s a game you play with Spanish Cards (different from Poker Cards) and you can play it 1 vs 1, 2 vs 2 or 3 vs 3. The goal of the game is to reach 30 points. You do that by “gambling” on your team’s cards and tricking the opponent to think they have better cards than yours. (To really explain the game, I’ll need three days, 4kg of meat and 10 liters of Fernet, if you still want to know how to play, read this or just comment on this post).

A few months ago I started playing Truco (almost) weekly with 3 friends.
Up until now we won more games than we lost (yay!).

Full disclosure, I had huge luck with my cards and received a lot of great cards.
But the real reason, I think, we are winning is not how we play when he have good cards, but how we play when we have bad cards or when one of us (mostly me) makes a mistake and costs us points, and that’s what I want to write about today.

The importance of knowing how to lose and how to minimize your loss. Everybody loses sometimes, in development I see “losing” as having a breaking bug in production that could’ve been tested or having an upgrade fail for some reason.
In truco, we tried to minimize our loss when we knew we were going to lose the hand. What that means? End as fast as possible the hand losing as few points as possible. While our rivals were trying to trick us when they had bad cards (and we didn’t fall for it) they lost much more points than we. Its sounds like the obvious thing to do, but sometimes you get involved too much and dig yourself deeper and deeper.

When I did something silly and lost us points we did a quick rerun and figured out what exactly we played wrong, mostly it was done in our heads and sometimes, when the situation was pretty bad, out loud. This took us no longer than 5 seconds and we were back on track to win the next hand.

Bugs in production and unsuccessful upgrades

We all make mistakes and sometimes we receive “bad cards” in our jobs. It’s important to know how to play these cards and, more important, to know that everybody was once (or twice) there.
If you have a good manager, he won’t “punish” you because you failed, but sit with you and try to figure out how to avoid this in the future (depending on how many times you’ve failed, of course…)

In my job we have a written assessment we fill each time something happens. The main purpose of it is to pin-point what was wrong so it won’t happen again. If you don’t have something like that I recommend it strongly. 

I’ve filled 4-5 of those (and still counting…) and never repeated the same mistake twice. Because that’s the real issue, not to repeat the same mistake twice.
You fill in what happened, how it happened (step by step), why it happened (what did you miss), and what needs to be done so it won’t happen again. That’s it. It takes maybe 15 minutes and you do it with your supervisor so there is an objective side to it. When it is written down you know you’ve given it a thought and focused on the incident.

This can be about a bug that got itself to the production; once our QA team missed a crucial test and “what wasn’t tested won’t work”, so we needed to rollback the upgrade. Or about an upgrade that didn’t go as planned; 6 hours upgrading a server instead of 3 hours because the cables weren’t connected to the correct NICs.

I can promise you that since these happened, they didn’t repeat themselves even once. And the main point is exactly that, to learn from previous incidents, from others and myself, to work better.

The important thing is not to overlook the mistake made and not to be afraid to be held responsible for it, but to own it and help others to avoid making the same mistake again.

Comments: 1

  1. Anonymous says:


Add your comment