You’ve probably heard the saying, “when life gives you lemons, make lemonade.”
Dale Carnegie, in How To Stop Worrying and Start Living wrote, “The fool, if he finds that life has handed him a lemon, he gives up and says, ‘I’m beaten. It is fate. I haven’t got a chance.’ But when the wise man is handed a lemon, he says: ‘What lesson can I learn from this misfortune? How can I improve my situation? How can I turn this lemon into lemonade?’”
The answer is a change of perspective.
In any field, a new outlook can make all the difference, as seen in the case of Clear Street Senior Software Engineer Tanishq Dubey. Faced with a stubborn bug that threatened his application’s integrity, he was advised to rewrite his code from a different angle. This fresh approach quickly revealed the issue, leading him to adopt code rewriting as a standard practice ever since.
Dubey recently spoke with Built In New York to provide more insight into how this unique engineering approach continues to result in sweet successes for him and his team.
Clear Street is building financial infrastructure for today’s institutions.
Describe one of the principles, habits or rituals that differentiates your engineering approach.
Though counterintuitive, not being attached to my code and rewriting it altogether. When developing software or thinking about a complex idea, it’s easy to get tunnel vision on a concept not worth addressing.
For instance, I was working on a bug that would ultimately corrupt my application’s memory. I isolated the issue to a few dozen lines of code but couldn’t find a solution. I even reread the code — hoping for divine intervention — but nothing helped. Then, a coworker suggested I rewrite it. I was hesitant, but after a simple rewrite, the issue was fixed.
Comparing my new implementation to the old one, the bug was painfully obvious. Rewriting isn’t always necessary, but a fresh perspective can change everything.
What differences have you noticed as a result?
The most significant difference was the amount of time rewriting saved me. Without being firmly attached to my work, I began to optimize my time by limiting how long I spent debugging code. If I’m unable to figure something out, I remind myself that I can always delete my work, start from scratch, fix the problem and compare my results to find the initial bug.
I help build innovative technology to replace legacy infrastructure across the financial industry through a single-source, cloud-native clearing and custody system. Learning to locate bugs quickly and resolve issues is crucial when systems move around 2.5 percent of the national equities volume daily.
Initially, I became eager to rewrite whenever I saw a bug. However, through experience, I learned not to delete the entirety of my work and recognized that chunks within a project can be quickly rewritten to solve a problem.
“You don’t want to boil the ocean, just the little space around you.”
What does this approach help you and your team accomplish?
Utilizing this approach helps my five team members and me keep our egos in check when writing and programming. Becoming attached to the code you create is common and understandable, but being overly attached can lead to individuals becoming obsessive and not accepting new changes to their work — even when it’s helpful. Implementing a methodology where all your work is on the chopping block levels the playing field and makes everyone more comfortable when contributing. In addition, being open to change and feedback leads to higher-quality work and a better final product.
As software engineers, we must focus on delivering something that works and is a pleasure to use, rather than something with beautiful code that is a nightmare for users.
