I thought I knew frontend until I started doing it professionally

When I started working at my first company in 2023, I already knew React.

At least, I thought I did.

I had built projects, worked with components, called APIs and knew enough JavaScript to get things working. Coming from university, that felt like a decent foundation.

Then I started working on an actual product with an actual team.

That was when I realised knowing how to build something and knowing how to build something properly were two very different things.

The first few months

I joined as a Junior Software Engineer, mainly focusing on frontend development.

Being a junior meant I was still heavily guided by the developers around me. Looking back, I think this was probably one of the most important parts of my early career.

A lot of the things I worried about back then were very implementation-focused.

How do I build this component?

Where should this state live?

Why is this test failing?

How do I get this API response into the UI?

I just wanted the feature to work.

But through code reviews and working with more experienced developers, I slowly started getting asked a different set of questions.

Is this reusable?

What happens when the API fails?

Does this belong inside this component?

Are we going to have to duplicate this somewhere else?

Can someone understand this code six months from now?

Those questions changed the way I wrote frontend code.

Getting it to work wasn't enough

One of the biggest changes for me was understanding that a working UI isn't necessarily a good implementation.

You can build a React component that looks exactly like the design and still end up with terrible code underneath it.

I started paying more attention to how components were structured, when logic should be moved into custom hooks, how state was managed and how much responsibility one component should have.

Instead of thinking:

"How do I make this work?"

I started thinking:

"How do I make this work without making the next person's job harder?"

Sometimes that next person was me two weeks later.

I also started testing my own assumptions

Testing was another big part of that transition.

I worked with Jest and Storybook quite a lot during my time there. At first, testing honestly felt like extra work after I had already finished the actual feature.

Build component. It works. Done.

Then write tests because I have to.

That mindset didn't last very long.

Once you work on a codebase where things are constantly changing, you start understanding why those tests exist.

A small refactor shouldn't silently break something completely unrelated. A reusable component shouldn't behave differently just because another developer uses it in a slightly different way.

Testing stopped feeling like something I did after development.

It became part of development.

Frontend also wasn't just frontend anymore

As I became more comfortable, the work started expanding beyond components.

I was working with REST and GraphQL APIs, React Query, Redux, Next.js and AWS services like S3.

One of the bigger pieces of work I eventually handled was an eKYC flow.

That involved much more than putting an upload button on a screen.

There was image processing, storing images in S3, passport and ID verification, Amazon Textract, MRZ extraction and connecting all of that back to the experience the user actually sees.

That project made something very obvious to me:

The frontend might be where the user interacts with the product, but you can't build a good frontend while completely ignoring everything behind it.

Understanding what happens after you send a request makes you much better at deciding what should happen before you send one.

The boring things started becoming important

When you're learning development, the exciting part is usually building something new.

Animations. New pages. New features. New libraries.

Professional development made me appreciate much less exciting things.

Naming.

Folder structure.

Error handling.

Loading states.

Responsive behavior.

Accessibility.

Refactoring.

Reading somebody else's code before changing it.

Leaving code slightly better than how I found it.

None of these are particularly impressive when shown in a screenshot.

But they are usually the difference between a codebase that is pleasant to work with and one where everyone is afraid to touch anything.

What does my first job actually taught me

I don't think the most valuable thing I got from my first professional role was React, Next.js or any particular technology.

Those were important, obviously.

But frameworks change.

The bigger lesson was learning how to think about code that other people have to work with.

Before working professionally, most of my projects belonged to me. If the code was messy but it worked, I was the only person who had to deal with it.

Working in a team changes that.

Your decisions affect somebody else.

Your component becomes somebody else's dependency.

Your API integration becomes something another developer has to debug.

Your shortcut today can become somebody's problem six months later.

I definitely didn't understand all of that when I first joined.

I probably still don't understand all of it now.

But that's also one of the things I like about this field.

Every time I start feeling like I know what I'm doing, I find another layer underneath it.

And I get to learn again.