Shuvangkar Das, PhD

1 minute read

I spent 3 months writing code that today would take me just 1 week not using AI.
Why?
Because I was trapped in an engineering mindset, not a research one. In my previous post, I shared how I changed my mindset and how it helped me a lot.

Back in 2018, I was building a grid-following solar inverter as a research project. Determined to keep costs down, I chose a $2 microcontroller with no floating-point support. That decision—made with good intentions—cost me months of productivity.

I remember staring at assembly instructions, debugging signals for hours, and optimizing every clock cycle to squeeze performance out of that tiny chip. I thought I was being smart—efficient.
But I wasn’t.
I was over-engineering a research prototype.

Today, I would simply use a Texas Instruments Launchpad, model the system in Simulink, generate embedded C, and deploy in days. The goal in research isn’t to perfect—it’s to prove., it’s to bring something new to the world.

🎯 The Lesson:

As researchers, our job is not to build production-grade systems.
Our goal is to test ideas, prove feasibility, and create reproducible results—not to perfect every line of code.

There’s a difference between productivity and reproducibility.
Yes, reproducibility is vital.
But so is using the right tool for the right job.

As Dr. Shah M Hasan put it beautifully:

“If the end goal is a PoC: let your researcher mind take the driving wheel. But if the end goal involves deployment, mix both personas.”

That perspective completely changed how I approach my work today.

💡 What about you?

Have you ever over-engineered a prototype or spent too long perfecting something that only needed to work once?
Let me know how you deal with the trade-off between engineering perfection and research output.

Shuvangkar Das, PhD
Knoxville, Tennessee, USA

☎ Connect with me

📚References

Updated:

Leave a comment

You may also enjoy