What I've Been Learning During My Internship at Diagno Energy

I've been interning at Diagno Energy, and one thing became obvious pretty quickly.

The work is real. The users are real. The mistakes are real too.

That changes how you think.

This is a short note on what has been sticking with me.

1) Shipping beats "perfect"

At uni and in personal projects, it is easy to keep polishing forever.

In a team, you learn to move in a way that is:

• Incremental - small changes are easier to review
• Testable - you can explain what changed and why
• Reversible - if something goes wrong, the blast radius stays small

That shift alone has made me better.

2) Data-heavy UI is a different beast

A big part of my work has involved UI that depends on data.

A few things clicked for me:

• The UI is only as good as the shape of the data you ask for
• "Just fetch everything" usually becomes a performance problem later
• The best UX is often fast and predictable, not flashy

Have you ever used a product that felt slow, even though nothing looked broken? A lot of that starts here.

3) Performance is often about restraint

I used to think performance work mostly meant optimizing code.

It does sometimes.

But a lot of it comes down to product choices:

• Do not render what the user cannot see yet
• Do not fetch what the UI does not need yet
• Keep heavy components off the critical path

One pattern that helped me was lazy-loading secondary UI:

import React from "react";

const DetailsPanel = React.lazy(() => import("./DetailsPanel"));

export function Page() {
  return (
    <React.Suspense fallback={<div>Loading...</div>}>
      <DetailsPanel />
    </React.Suspense>
  );
}

Simple, but useful.

4) "Good enough" queries do not stay good enough

I have learned to respect the gap between:

• A query that works
• A query that still works well six months later

Reducing payload size, avoiding over-fetching, and asking "what do we actually show?" makes a real difference.

Especially when the UI has maps, side panels, or drill-down views.

5) Clear communication is part of the job

The best engineers I have worked with are also good communicators.

• They explain why, not just what
• They ask questions early
• They leave enough context behind that the next person is not guessing

I have been trying to copy that.

Small updates help. Clear PR descriptions help. Admitting "I am not sure yet" early helps even more.

6) Feedback is where the growth is

Code review has probably been the highest-signal learning loop for me so far.

The goal is not just to "get it approved."

It is to understand:

• Why one approach is preferred over another
• What patterns the codebase already leans on
• What risks I missed the first time around

What I am taking forward

If I had to keep a short list, it would be this:

• Start small, ship safely, then iterate
• Performance is a product feature
• Ask for less data and shape it better
• Write code for teammates, not just for compilers
• Feedback loops matter more than ego

If you are early in your career, maybe you have felt this too.

You do not become ready first. You get ready by doing the work.