Sometimes, getting fired by — or having to deal with — an unreasonable manager can turn out to be the best thing that ever happened to a budding entrepreneur. Not only can such experiences inspire you to question the status quo, but they can also impel you to think deeply about the problems you’ve encountered and to figure out new ways to solve them in the future. Over the course of my 20-plus year career as a software engineer, I’ve lost jobs and/or been reprimanded over issues that ultimately led me to create my company, Zettabytes, and to devise the most compelling and useful features in the new collaboration platform called Roost that we’re launching soon. Here’s how that came to pass.
1. The developers’ herbal collaborative nature was poorly seen.
In the early 2000s, while working at a unified mobility startup, I introduced my manager to a finished product I had been running. Your reaction to my paintings is shocking. I had noticed other developers in my office, evaluating the task and giving me feedback. My manager’s conclusion: “I’m horrified that you had to ask everyone for help to make it work.”
For developers, mutual mentoring is everything that arises in a very natural way; We went out together, we talked about the code, we inform each other. But my manager couldn’t settle for that, and three months later I was released. That was in 2001, the collapse of Dot Com, and it was hard to find work. So I packed up and went back to India, where I worked on the first Java-based email server with my Zettabytes co-founder, Sudhir Jangir.
Today, years later, unlike this past experience, our Roost platform celebrates developer collaboration; in fact, this is probably Roost’s ultimate life characteristic. Developers can collaborate informally with others in real time and create better products. What’s not to like?
2. The introverted nature of developers can work against them.
The software progression procedure involves, by necessity, many repetitions, and developers have to check various approaches before they know what works. The traditional wisdom is that each and every replacement made through a developer will have to be approved by many others. This practice pushes developers to percentages of code before they think it’s ready.
In 2006, I applied to the invoice department of a primary monetary institution. I am a component of the UI team and relied heavily on the server team. One day, a thorny factor emerged and I contacted the leader of the opposing team. Instead of solving my problem, the manager complained to their manager, who in turn reminded me how important it is not to break their construction. Later, the same senior team member tried to sabotage me when I implemented for an additional assignment at the same monetary institution.
The lesson: Developers want an environment in which they can innovate before the code is in a position to be published for a wider audience. This lesson led to the Roost platform’s moment feature: service collaboration. The developer can now verify your service before it gets up and running. This makes simulated installations irrelevant. Simulated installations are remnants of the afterlife where you tried to catch a moving target with blurred vision.
3. Real-time sharing is essential.
In 2008, I joined the algorithms and analysis department of a giant streaming company whose main activity was sending DVDs. It is our task to use knowledge science to wait for a DVD call for the next day.
There were three members on our team, and I was the youngest of them. Shortly after my arrival, one member said goodbye and the other left for a week. Only I stayed, and now I had the duty of the code, because our team had suddenly been reduced to a skeletal team of one.
Now you may think these things are routine and that it’s rare for any truly major issue to arise. For me, luck played out slightly differently. I got a call on Monday morning at 6 a.m. saying there was an outage and the DVD shipment had come to a standstill.
I tried to run the application’s codebase and temporarily discovered that something wasn’t working. It’s a race that’s counter-time, so I looked for alternatives. I discovered something strange. At the time, the main types of media such as HD, Blu-ray and DVD were known by numbers 1 to 4. For some reason, those in our formula earned less than 1 as a support type. There’s no less than 1.
Then I asked the order control team. They said they had no idea what I was talking about. Fortunately, I asked the database team if they could reassign it from minus 1 to 1. The database team and my manager think I’m wasting it seriously, but since they had no choice, they started doing it. I asked, how long will it take? They said probably 10 minutes. Ten minutes later, the total formula worked again. Nirvana.
And so, real-time sharing of upstream and downstream services was to become another new feature. I’ve learned how to learn from mistakes, proving again that glitches and hardships can often pave the way to success, and encourage you to do the same.