Field Notes

One of the things I underestimated about software engineering was how much of the job involves understanding something you didn't design.

At CDPI, I spent a lot of time reading Java services written long before I joined the project. The code didn't come with an explanation of why a particular abstraction existed, why a service depended on another one, or which behaviour was important enough that changing it would cause problems somewhere else.

You have to reconstruct that context from the system itself — the code, the database, the messages moving between services, and sometimes the things that break when you change them.

It changed how I approach unfamiliar codebases. I don't want to understand every line before making a change. I want to understand what the system is trying to do, what it depends on, and what I cannot afford to break.

The most interesting engineering problems I've worked on have usually started with a restriction.

At NTIRE, the model had to fit within 1 MB. At E-Sannidhi, connectivity couldn't be assumed. At CDPI, the system already existed and the migration had to preserve its behaviour.

Constraints initially feel like limitations. Eventually, they become useful because they force you to decide what actually matters.

I've started asking a similar question even when nobody gives me a hard constraint:

If I couldn't afford to add another layer or another dependency, what would I change?

Sometimes the answer is surprisingly simple.

There is a difference between getting something to work and understanding why it works.

A model can produce a good result. An API can return the expected response. A query can become faster. A service can pass its tests.

But those outcomes don't necessarily tell you what is happening underneath.

The more systems I work on, the more interested I become in the second question: why?

Why did this query become slow? Why did this model improve? Why does this service need this dependency? Why does the system behave differently when the network disappears?

Those questions are usually more interesting than the first solution that makes the problem go away.

Research taught me to be comfortable when the answer isn't obvious.

You can change an architecture, train another model, adjust the preprocessing, or run another experiment and still not know whether you've actually made things better.

Engineering adds another layer to that uncertainty. A result that looks good in isolation still has to survive the constraints of the system around it.

Working across both has made me less interested in chasing complexity for its own sake. I care about whether an idea survives contact with the actual problem — the data, the infrastructure, the constraints, and the people who eventually have to use or maintain it.

I used to think performance optimization was mostly about knowing the right technique.

Then I spent enough time looking at actual systems to realize that intuition is a pretty unreliable profiler.

Sometimes the obvious bottleneck isn't the bottleneck. Sometimes replacing something with a more sophisticated solution would solve a problem that better measurement would have shown wasn't there in the first place.

So now I try to start with a simpler question:

What does the measurement actually say?

If I can't explain what changed, why it changed, and what I gave up to get that improvement, I don't consider the optimization finished.