Building Software Is the Easy Part

When Mani Senthilnathan Vignesh began studying Computer Science at NTU, he thought becoming a good engineer was straightforward.

Write clean code. Design efficient algorithms. Build software that works.

Like many aspiring software engineers, he saw coding as the heart of the discipline.

It did not take long to realise there was much more to engineering than the code itself.

"I came in thinking Computer Science was mostly about being a strong individual coder," he says. "What changed my mind was realising most of the actual craft is about systems. Systems of people, systems of decisions, and systems that have to survive contact with requirements nobody fully understands on day one."

That shift in perspective transformed the way he approached every project that followed.

Winning the Tata Consultancy Services Gold Medal was a proud milestone, but for Mani, it represented something beyond academic achievement. It was recognition for learning lessons that could never be measured by code alone.

One of those lessons came during Software Engineering, a module he admits he found challenging.

Rather than focusing solely on how to build software, it forced him to understand why software fails in the real world. There were late nights debugging, documentation rewritten more than once and moments where solving the technical problem was only part of the challenge.

"Winning the TCS Gold Medal feels less like recognition for a clean grade and more like validation that the messier, harder-won parts of the module actually paid off," he reflects.

Another defining moment came during a team project in Object-Oriented Programming.

As project requirements evolved and teammates worked to different schedules, Mani discovered that successful software projects depend on far more than technical ability. Communication, shared understanding and collective decision-making became just as important as writing elegant code.

The experience led him to an observation that continues to shape how he thinks about engineering today.

"Most software failures are coordination failures wearing a technical costume."

Outside the classroom, those same experiences strengthened the friendships that carried him through university life.

With deadlines, projects and commitments often converging at the same time, having course mates who understood the journey made all the difference. They celebrated successes together, laughed through setbacks and reminded one another that no one had to navigate the toughest weeks alone.

"My friends taught me that good engineers argue about trade-offs while good teammates know when to stop arguing and ship," he says.

As he prepares to enter the profession, Mani believes those lessons have become even more relevant.

Artificial intelligence is dramatically reducing the time it takes to turn ideas into working software. But while the tools are becoming more powerful, he believes the real challenge has not changed.

"The bottleneck is shifting back toward judgment, taste, and knowing what to build and why," he says.

For the next generation of engineers, technical skills will always matter. But so will understanding people, making sound decisions and learning to navigate complexity when there are no perfect answers.

That is why his advice to juniors is surprisingly simple.

Don't choose the modules that feel easiest.

Choose the ones that challenge the way you think.

"The module that annoys you most in the moment is usually the one that ends up teaching you the most about actually building things that last. So don't optimise for the modules that feel good; optimise for the ones that challenge you most."

After graduation, Mani plans to pursue opportunities at the intersection of finance and technology before taking a well-earned break to celebrate the end of university life.

He leaves NTU with technical knowledge, certainly.

But perhaps more importantly, he leaves with a deeper understanding that while writing software is difficult, building systems that can withstand changing requirements, differing perspectives and real-world uncertainty is harder still.

Because the real challenge isn't writing code.

It's navigating complexity.