Blocking the checkout. The real take from it.

I'm going through an interview process, and a question came up that I really enjoyed. We developers are used to telling our success stories and how many medals we have in our war chest. But what about the dark times, the errors that still haunt us, the bugs that we introduced silently... our skeletons in the closet?

Don't be afraid of them! Those are the actual learning experiences that made you grow. Own them; that's where real ownership comes from. No recruiter or manager will be impressed only by your self-flagged success stories. In reality, how could they know if those stories are actually true, or how much we spiced them up to get the job?

Errors, on the other hand... tell something more interesting. Of course, you can put it on others or on “a network” glitch, but the real deal comes from how you communicate it post-forensics. What did you learn from it? What changed? Just think about it. Do it with yourself, without fear, go in, and you could be surprised.

For me, the issue that I picked for my answer was one I delivered to production, entirely my fault, and it is, in itself, at the very least, embarrassing. Incoming meaty details!

The Ticket

The ticket was pretty simple, so let's just assume it read something similar to:

Task:
Add a new custom attribute data-foo to the Pay Now CTA. This attribute has to do...

So, I made the code changes, and since I was working on a template file, it contained some JS and some HTML. I added the attribute and the tracking or whatever the ticket was about. I can't really remember. But it was a pretty easy task, one of those trivial tickets... that I will never forget.

You can already know where this is going... I mean, the title is a bit of a spoiler. But it's intended, I assure you. Remember a couple of paragraphs before... The value is in the story; the lesson lies there.

The ticket moved forward and reached the “peer-review” stage. It was sent back because of this or that, nothing major. I made the changes and merged my branch.
Deployment shortly followed.

Our monitoring was a customer with a phone.

We found out about 25 minutes later. The Pay Now CTA was not working, so users could not finish the checkout process.

We rolled back.

Our test coverage told us how much code the tests touched, not whether the critical path where money moves still worked. Lesson learned. Shortly after, we implemented hardened code checks and E2E testing.

The whole point here is not to expose anything; it's just a reflection on what we can take from mistakes and how blaming doesn't help at all. In this case, yes, there is a culprit: me. Yes, the company lost some sales. But if you flip it, we learned how vulnerable we could potentially be if we just “stick” to the process and never look at it again.

This incident, in spite of leaving us in a weak spot and exposed, formed what became a great team: one that took responsibility for its own mistakes and wasn't afraid of saying that something might go wrong.

That's how strong teams are built. Support and open communication.

Hooked? Keep digging: https://oscar-azpeitia.com/tag/career/