Unlearning my way to better systems

The biggest jumps in my career didn't come from new frameworks. They came from letting go of beliefs I was sure were right.

From tables to workspaces

When I started, I thought frontend was about displaying what exists in the database. A table here, a form there, a create-read-update-delete screen for every entity, an API behind each one. If the data was on the screen and editable, the job was done.

Now I think in workspaces, personalization, workflows and productivity. A registrar doesn't want a "students table". They want to know which students need attention this morning, what is stuck, and what they can finish before lunch. An admissions officer doesn't want a list of applications. They want a queue that tells them who is waiting on them and for how long.

The database is the raw material. The product is the work it makes easier. Build screens around tables and you get data-entry sheets. Build them around the people doing the work and you get a system they want to open.

Data is king

I used to over-optimize. I was almost afraid of storing data. Why save it if I could compute it? Why keep history if the current state was all the screen needed?

Then the questions started. When did this status change? Who changed it? How long did it sit there? What did this record look like last semester? Every one of those questions had the same answer: we didn't keep it, so we can't know.

Now I understand that every single piece of data matters. You can always derive a number from facts you stored. You can never get back a fact you threw away. Optimization is about storing and serving data well, not about losing it.

There is one part I'm still learning. Data is also a responsibility. Keeping something means knowing why you keep it, who owns it, and how you protect it, especially when it is personal. Valuing data and respecting it go together.

From developer experience to the business

Early on, my decisions were about me and other developers. Is this pattern clean? Is this library nice to use? Is this the most elegant way to write it?

Those questions still matter, but they are no longer first. Now I start with the business and the domain. What is the institution trying to achieve? What do the stakeholders need to decide? What will make an end user's day easier, or harder?

Good developer experience isn't the enemy. It's how a team keeps delivering for the business year after year. It just serves the goal. It isn't the goal.

The hard part was unlearning

None of this came from reading a book. It came from unlearning things I had been taught and believed in. Some were rules I defended in code reviews. Some were ideas I was proud of. Some was plain ego.

It's uncomfortable to admit that something you argued for was the wrong call. It's even harder to change how you think, not just what you write. Every one of these shifts started with being wrong in front of someone.

I didn't get here alone. I'm grateful to my seniors and managers who challenged me, asked the uncomfortable questions, and pushed me to look past the code at the people using it. Much of how I think today, I learned from them.

These lessons are why I now build systems instead of data-entry sheets. I still have a long way to go, but I'm proud of this progress. It wasn't easy.

To those just starting out

If you're early in your career and suspect you're thinking about all this the wrong way, that's normal. Everyone goes through it. Experienced developers know this, because they went through it too.

Time is the best teacher, and real users are close behind. You'll ship something you think is perfect and watch someone struggle with it. That moment teaches more than any tutorial.

A few things that helped me:

• Ask who it's for. Before the schema, before the component, ask who will use it and what they're trying to get done.
• Keep the facts. Store what happened, not just the current state. Future you will need it.
• Hold your opinions loosely. Defend them with reasons, and drop them when the reasons stop holding.
• Learn from the people around you. Your seniors have already made the mistakes you're about to make. Ask them.

We never stop making mistakes. We never stop learning. There is always room to grow, and that is the best part of this job.

Where I'm heading

I want to keep learning. I want to become a system architect: someone who understands the domain, shapes the decisions, and sees how the pieces fit together for years to come.

That matters more now than ever. Tools and AI agents can write more code every month. Typing code is becoming the cheap part. The valuable part is judgment: knowing what to build, what to leave out, and why. I don't want to be just a coder or just the person who runs the agents. I want to be the one who decides what good looks like.

The journey so far has been about unlearning. I expect the next part will be too.