A Year of Building and Becoming an Engineer

A year ago, I thought I knew what software engineering was.

I had built projects, worked internships, learned different technologies, shipped things, and spent countless hours writing code. But looking back, I think I understood programming much better than I understood engineering.

Over the last year, that distinction has slowly started to become clear to me.

And the funny part is, this wasn't a year where everything went perfectly. There were days when I genuinely wondered if I was done. Days when I questioned what I was doing with my life, where all of this was headed, and whether I was actually good enough to keep up.

At the same time, the industry around me was changing faster than I could process. AI was getting better at writing code at an incredible pace. Tools were getting easier. Agents were becoming more capable. And alongside that came layoffs and uncertainty across the technology industry.

So this year wasn't just about becoming an engineer. It was about trying to become one while the definition of engineering itself was changing.

---

From writing code to understanding systems

Earlier, a lot of my thinking was centered around the code. Can I implement this? Can I make this API work? Can I learn this framework? Can I finish this feature?

Over time, that started changing.

A feature isn't just the code you write. It's the dependencies around it, what happens when something fails, how it behaves under unexpected input, how someone else will understand it months later, how you test it, and how you debug it when it breaks.

I started moving from "How do I make this work?" towards "How should this work, why should it work this way, and what happens when it doesn't?"

That shift has probably been one of the biggest changes in how I approach engineering.

From completing tasks to owning them

One of the biggest lessons I've received this year has been around ownership.

Ownership isn't just taking a ticket and writing the code. It's understanding the problem before jumping into implementation, asking questions, thinking about edge cases, testing properly, following something through after the code is merged, and ultimately being willing to say, "This is mine. I am responsible for the outcome."

A lot of this came through feedback from the engineers I work with at Sei AI. And importantly, it hasn't been one person. Multiple people have invested time in helping me become better.

The code reviews, technical discussions, feedback sessions, and conversations I've had with the CTO and other engineers have gradually changed the way I think about my work. A lot of the feedback wasn't simply "write better code." It was "think more deeply," "take ownership," "test this properly," "follow this through," and "why did you make this decision?"

Getting that kind of feedback this early in my career has been incredibly valuable.

At one point, I even burned out trying to do too much, learn too much, and prove that I could keep up. What helped wasn't simply working harder. It was having people around me who helped me understand how I should be working.

That distinction matters.

The places that shaped me

My growth didn't happen in one place. Each experience gave me something different.

At Parsewave, I got an early look at the realities of working on software professionally. It wasn't always easy, but it gave me lessons that I couldn't have learned from college projects alone. Some experiences teach you through things going well; others teach you by showing you what you don't want to repeat. Both matter.

Then came HealthPilot AI.

HealthPilot took a pretty big bet on us early in our careers. We were a young team, with many of us coming straight out of college, and we were given the opportunity to actually build.

I had to figure things out. I had to ship. I had to make decisions with incomplete information. I had to learn by doing.

That experience accelerated my growth tremendously. Looking back, I'm incredibly grateful that someone was willing to take that bet on us. Sometimes the biggest thing you need early in your career isn't another course or another certification. It's an arena where you're allowed to build.

Then came Sei AI, which has been a different kind of experience.

I've been surrounded by engineers much more experienced than me, and I've had the opportunity to see what good engineering looks like up close. I've made mistakes, gotten things wrong, received feedback, and had to rethink how I approach problems.

The conversations aren't always about the code itself. Sometimes they're about how I approach a problem, how I communicate, how I take ownership, or what I should have thought about before writing the first line.

The people who were there outside of work

I also don't think I can tell this story without talking about the people outside of work.

There were nights during college when I was struggling with placements and genuinely wondering what was going to happen next. I had significant work experience by that point, but that didn't make the uncertainty any easier. There were nights when I'd call my friends late and just rant about not getting placed, whether I was good enough, and what I was going to do next.

They listened.

Sometimes for hours.

They didn't necessarily have solutions. They just stayed. They reminded me that one rejection, one bad week, or one uncertain period wasn't going to define my life.

Those friends have been a huge part of my life, and I don't think I acknowledge that enough.

And then there's my family. My parents have been there through all of it — the uncertainty, the pressure, the wins, the failures, and everything in between. A lot of what I've been able to do comes from having people who believed in me even when I wasn't completely sure about myself.

You don't become an engineer in isolation. There are people behind the person who eventually writes the code.

The part the GitHub graph doesn't show

Over the last year, my GitHub shows 3,527 contributions.

It's a cool number, but it doesn't tell the story.

It doesn't show the hours spent staring at something I didn't understand, the bugs, the failed approaches, the PR comments, the debugging sessions, or the conversations where someone explained something I should have already known. It doesn't show the moments where I questioned whether I was actually getting better.

The graph shows how much I built. It doesn't show how much I changed.

And that's probably the metric I care about more.

From technologies to fundamentals

At some point, I stopped being as interested in asking, "Should I learn X?" or "Should I use Y framework?" and started asking different questions: What problem are we actually solving? What are the tradeoffs? Why does this system work this way? What happens underneath this abstraction?

Frameworks change. Libraries change. Languages change. Tools change.

But fundamentals compound.

Databases still have tradeoffs. Networks still behave like networks. Systems still fail. Engineers still have to make decisions.

And then AI happened

This has probably been the strangest part of becoming an engineer right now.

Things that used to take hours can sometimes be generated in minutes. The cost of producing software is falling.

And that raises an uncomfortable question: If AI can write more and more of the code, what does it mean to be a good software engineer?

I don't have the answer yet.

I don't know what software engineering will look like five or ten years from now. I don't know how much of the work engineers do today will still exist in the same form.

But I have started believing that the answer probably isn't trying to compete with AI at typing code faster.

If code generation becomes abundant, then understanding what should be built, why it should be built, how it fits into a system, and whether it is actually correct becomes even more important. Judgment matters. Fundamentals matter. System understanding matters. Ownership matters. And knowing when the machine is wrong matters.

In a strange way, AI has made me more interested in becoming better at the parts of engineering underneath the code.

The uncertainty is part of it

I'm still figuring it out.

The industry is changing. AI is changing. The way software gets built is changing. And I'm changing with it.

Maybe that's part of what makes this such an interesting time to become an engineer.

I don't know exactly where my career is headed. But I know I still want to build. I still want to understand how things work. I still want to become ridiculously good at the fundamentals. And I still want to see how far I can take this.

The impact beyond engineering

This year also changed my life outside of code.

Working professionally gave me a level of financial independence and responsibility that I didn't have before. It allowed me to support my family, make decisions I couldn't make earlier, and think about the future differently.

Money matters. But I've started seeing it differently.

The money changed some of my circumstances. The engineering changed me.

The bigger shift was realizing that becoming useful, solving difficult problems, creating things, and becoming someone people can rely on has value. And that's something I want to keep compounding.

I'm extremely grateful

If there's one thing I don't want this post to become, it's a story about doing everything alone.

I didn't.

Multiple people have invested time, patience, and belief in me. And I don't take any of that for granted.

Sometimes someone gives you an opportunity. Sometimes someone tells you that your approach is wrong. Sometimes someone gives you enough room to make the mistake yourself. And sometimes someone simply stays on the phone while you're having a terrible night.

All of those things matter.

---

One year later

A year ago, I wanted to become better at programming.

Today, I want to become someone who can understand, build, operate, and take responsibility for systems. Someone who can take an ambiguous problem and turn it into something real. Someone who understands the fundamentals underneath the abstractions. Someone who can work with people, make decisions, handle uncertainty, and stand behind what they've built.

I'm nowhere near that person yet.

And strangely, I'm okay with that.

Because I think I've finally understood that this isn't a destination.

It's a craft.

There were days when I thought I was done. There were days when I questioned the future. There were days when I felt like I wasn't good enough. And there were days when something finally clicked.

All of them were part of the same year.

A year of building. A year of failing. A year of learning. A year of becoming an engineer.

And after everything I've learned, the biggest realization is probably the simplest:

I'm just getting started.