What real product work changed for me

Before my internship at Diagno Energy, I mostly thought about frontend performance as a code problem. The internship made it a product problem.

The interface had real users, the data had real edge cases, and every change had to fit into work already happening around it. These are the lessons I want to keep.

A working query can still be the wrong query

A query is not finished just because it returns the right rows. It also needs to return the right shape for the screen using it.

That meant asking a few questions before touching the component:

• What does the user need to see first?
• Which fields are only needed after another action?
• Can the API return a smaller payload for the initial view?

The cleanest UI work often started by asking for less data.

Loading order is part of the design

Some screens had maps, panels, and drill-down views competing for the same initial load. Rendering all of it immediately made the product feel slow even when each piece worked.

I started treating secondary UI as secondary in the code too. Lazy loading was one useful tool, but the bigger change was deciding what deserved to be on the critical path.

The non-happy paths are still the feature

Data-heavy UI spends a lot of time between clean states. A request can be slow, a result can be empty, or one part of the page can fail while the rest is still useful.

Those states cannot be added as a final polish pass. They affect the component structure, the copy, and sometimes the API response itself.

Small changes move faster

The most useful pull requests were not the biggest ones. They had a clear purpose, a small review surface, and an obvious way back if something went wrong.

That changed how I break down work:

1. Make the smallest useful change.
2. Explain why it exists.
3. Test the failure path as well as the normal one.
4. Leave enough context for the next person.

Code review is an engineering tool

Review was where I learned the local rules of the codebase: which patterns were already trusted, which risks I had missed, and why one implementation would be easier to maintain than another.

Getting a change approved mattered. Understanding the feedback mattered more.

What I do differently now

I ask about the screen and the data contract at the same time. I keep optional work away from the first render. I write down the failure mode while I still remember it.

Most of all, I no longer think "works" and "ready" mean the same thing.