Skip to main content

What I learned from a $1000 mistake

 Recently I read a Reddit post that was posted on the subreddit r/cscareerquestions. It was posted by a junior developer from the U.S, who travelled across the country for his very first job. In the first week, he was given access to the production DB (But why?). With some false judgement from his side, everything went into mayhem. Long story short, the production data was gone...poof, just like that. A hefty price for a mistake from a junior dev. The guy was fired, and the company said they will take legal actions against the fellow.

I am not supporting the junior dev here on his mistake, but in a world, where we celebrate every single minute of success, why don't we ever hear about failure stories much?
Failure is the best teacher in many ways, isn't it?
I like to share my failure story from my very first company, and how I made a database error that cost my company around $1000.

I was working on my very first project back in my first company. Let's say for privacy sake the project I was working on is for a company named X. X is a multi-million company with lots of data at stake every day.
I was allowed to work around their some entity and its cost-related problems. With a lack of understanding or miscommunication from one of my BA (and from my end), I miscalculated a business idea, that leads to an entity getting swapped by yet another entity. result? A total amount loss of $1000, since the original entity, costs more than the new misplaced one. So now the customers who originally chose the old entity gets the cost of the new misplaced one, which is particularly cheap compare to the old one. Thus causing a huge loss in terms of money for X. (This is not the actual gist but for the sake of simplicity let's assume so)

Luckily I understood the problem that I caused and by the time I fixed everything $1000 was registered as a loss.
 
This was a great lesson that paved the way for my development career, and how to look into a problem twice. That taught me there might be a hidden problem lying somewhere waiting to be discovered. This experience of mine was so helpful when I worked on another project 2 years later for a company Y. They had a database design on firestore, that they were so adamant to implement, even though it was not economical. My past failure helped me to judge the cost implications of that bad design and I was able to show them an alternate design pattern, which helped them reduce the cost without compromising on usability and UX, which I am so proud of.

The same experience helps me whenever I try to integrate cloud services or payment services like the stripe on my projects, and helps me to ask "Is there a much more efficient and cost-effective way"?

So was my mistake a good thing or a bad thing? I don't know the answer to it even now. But I like to see it as a bad mistake with good future implications.

Maybe our failures can shed some light on younger generations. so that they avoid these mistakes when they start their journey. Maybe that's why StackOverflow is so a popular site. It is a collection of questions and mistakes. Right?

 

Talking of failures, this blog post is an inspiration  for this writing. Do check it out.

Comments

Popular posts from this blog

A smoooooth operation....

 Backward compatibility...   A word that I used to hear when I started my career. You design your APIs with backward compatibility in mind, don't break anything when you are upgrading, think about this, think about that etc. Well, those teachings from my previous mentors didn't go in vain, as I made a fundamental change in how we report problems @  Gelato .    You see recently @  Gelato , the CS (Customer Support) team moved from A ticketing management system to B ticketing management system, which is a monumental task for all the people involved in the CS team. Even though the fundamental concept remains the same the places, the attributes the concepts, and the naming of different attributes all change if you have this transition. And thus it was a big change for the whole company.    After the decision was taken, the first step was to create a well-written transition document, which the good folks at the CS team tackled. Special thanks to  ...

AI. Will it replace us or...?

AI!! The buzzword is too hot in the market nowadays. Do you have a technical product or an idea? If it doesn't have AI in it, then chances are it's not going to be sold like hot cakes. That is how things have changed lately. It is no wonder why me and my colleagues at Gelato want to see what AI can do in a niche department like customer support and service. And that is exactly what we did. For a company like Gelato, which is in the market for production-on-demand, there are a lot of customer questions you need to answer. It can be related to products, queries about shipping and pricing, and so on and so forth. Thus, our customer support team is always happy to help with these recurring questions. Let's take one example. A customer asked us, "Do you ship to Norway?" Now that is an easy question to answer if you have the knowledge written somewhere where you could refer to it and say, "Yes! As a matter of fact, we do." Following the same thread, the next q...

The alter egos of firebase

 So I was tinkering around the internet as usual, when I came to know about open source alternatives to some of the common tools that we use day in day out. That's when I came to know about firebase alternatives. A service that I used more often to come with a small POC of anything that I want to try out. A couple of the alternatives were  Appwrite  and  Supabase .   I started with appwrite initially, their self-host policy was really awesome and how easy to set it up and get started.    I created a small application on top of appwrite, that I am currently using for my company internal documentation storage. Since it's on top of docker image and resource-heavy I could not deploy it to my AWS free tier server. So sorry about not showing you guys a demo.   After working on top of it, these are my main findings;   Positive   Easy to use, no doubt on that Pretty straightforward documentation on about implementing the features support for a v...