In interviews, I’m often asked about situations where I took initiative. One story I always share goes back to 2017, when I joined Omnikick.
During my very first week, I spent hours scrolling through the codebase. What I found wasn’t pretty:
Files with more than 1,500 lines of code.
Single functions ballooning to 700 lines, and no clear organization, scrolling endlessly to find anything, was the norm
Database queries were pulling entire tables with no pagination or streaming
The codebase relied heavily on an outdated library called co(wrapper for async-await kinda flow control)
Heavy use of Lodash for utilities like map, reduce, and filter—all of which were already natively available in ES6
Different developers had their own coding styles, with no standardization in sight.
Oh, and testing? Barely existent, with a few scattered, ineffective test cases. Any change required manual verification, which was a nightmare.
It was clear that the team focused on “just getting things done” rather than building maintainable code. I didn’t want to continue that way. I saw a lot of potential for improvement and couldn’t just sit back and let outdated practices slide. I wanted to make a difference, even if it meant starting small. My first goal was to upgrade to the latest LTS version of Node.js. This would let us ditch the co library for native async/await syntax and leverage built-in ES6 features, reducing our dependency on third-party libraries like Lodash.
The project manager (who also doubled as QA) wasn’t convinced; it meant regression testing everything, and he wasn’t up for it. But luckily, our team lead agreed with me. Within about two weeks, I refactored 6–7 services with a couple of minor bugs, which I fixed quickly. We’re able to deploy these changes to production without any problem, a big win for the team.
Two months later, a new colleague joined who shared my passion for clean code. Together, we contributed to many things. We rallied the team, bit by bit, to embrace better practices. We broke down those monstrous 700-line functions, centralized business rules and data models that were scattered across services, and introduced ESLint to enforce consistent coding standards. Over time, the codebase became far more manageable, and the team started to see the value in maintaining a clean, standardized system.
Fast forward to when I moved to the Netherlands. I was relieved to find a culture that embraced code maturity. Here, people encouraged proactive improvements. It was refreshing to work in an environment where best practices weren’t just lip service; they were a priority.
This whole journey taught me that keeping our tools and practices up to date isn't just about chasing the latest trend. It’s about security, performance, and maintainability. It’s about creating a work environment where developers can be productive and confident. Every dependency we can remove is one less thing to audit and maintain. Every consistent pattern we adopt makes it easier for everyone to contribute.
It all starts with one person willing to ask, "How can we make this better?"
