The Engineer I Was, the Engineer I'm Becoming

The Engineer I Was, the Engineer I'm Becoming

On building software, getting things wrong, learning from people, and realizing that a career doesn't follow the roadmap you imagined.

Summary

I graduated in 2025 thinking I had a reasonable understanding of software engineering. I'd already spent years experimenting with technology, building applications, working on client projects, and learning how to turn ideas into working software.

Then I entered the enterprise world.

The programming languages were familiar. The problems weren't.

Over the following year, I worked on cloud platforms, enterprise integrations, AI prototypes, and systems that required far more than writing code. I also continued teaching, speaking at technical events, earning certifications, and eventually writing a book.

Somewhere along the way, my understanding of what it means to be an engineer began to change.

This isn't a story about how much I've achieved. It's about what I misunderstood, what I've learned, and the kind of engineer I'm still trying to become.

I Thought I Knew What Engineering Looked Like

When I was in college, I enjoyed building things.

That was probably the simplest way to describe my relationship with technology.

I liked starting with an empty project, writing code, connecting a database, building APIs, and watching something gradually become functional.

There was something satisfying about being able to point at an application and say, "I built that."

I spent a considerable amount of time working with web technologies, backend frameworks, databases, and cloud infrastructure. Alongside college, I also worked on real client projects.

Those experiences taught me things that classrooms couldn't.

Clients didn't particularly care whether I had used the latest framework. They cared whether the application worked, whether it met their requirements, and whether I could deliver what I had promised.

Still, most of my thinking revolved around implementation.

If someone described a problem, I started imagining the code.

Which framework?

Which database?

How should the API work?

How should I deploy it?

I was learning how to build software.

What I hadn't fully understood was everything that happens after software has been built.

The Difference Between Building Something and Being Responsible for It

One of the projects that shaped my early engineering experience was Dentist Channel Online.

It wasn't simply another website that needed a frontend and a backend.

It was a platform with actual users, content, integrations, and expectations around availability.

Working on a system like that changes how you think about relatively ordinary engineering decisions.

A database query isn't just a query when it's executed repeatedly under traffic.

An API response isn't just a JSON object when another part of the application depends on its structure.

A deployment isn't simply a successful build when users expect the application to remain available.

I started appreciating the less visible work.

Investigating performance problems.

Understanding database behavior.

Thinking about what happens when an external service is unavailable.

Making changes without unnecessarily disturbing existing functionality.

The interesting thing about production systems is that they don't care how much effort went into writing the code.

They care whether the code behaves correctly.

And when something breaks, the system doesn't care whether the original implementation was elegant.

Someone still has to fix it.

That experience taught me something I hadn't appreciated enough:

Building software is only the beginning of being responsible for it.

Then Came Enterprise Engineering

I joined Kyndryl in 2025.

Coming from college and client development work, I was familiar with writing software and delivering applications. Enterprise engineering introduced a different kind of complexity.

There were established systems, existing processes, multiple teams, customer requirements, access restrictions, approvals, and dependencies that weren't always under my control.

A change that looked straightforward technically could require coordination with several people before it could be implemented.

Sometimes the difficult part wasn't figuring out how to make something work.

It was understanding why the system worked the way it did in the first place.

Why was this integration designed this way?

Who owned the application?

What would happen if a field changed?

Which system was supposed to be the source of truth?

Who needed to approve the change?

And who would be responsible if something went wrong?

Those questions weren't always answered by reading documentation.

Sometimes I had to ask people.

Sometimes I had to investigate the system myself.

Sometimes I discovered that the original design made sense under constraints I hadn't initially considered.

And sometimes I found things that could have been designed differently.

Enterprise engineering taught me to be more patient with problems I didn't immediately understand.

Not every unusual implementation is bad engineering.

Not every complicated workflow exists because someone overengineered it.

Sometimes you're looking at the result of years of requirements, compromises, migrations, and decisions made under circumstances you weren't there to witness.

Understanding that history is part of understanding the system.

The Code Wasn't Always the Hardest Part

Working on enterprise integrations reinforced this lesson.

Consider synchronizing incidents between two IT service management platforms.

On paper, the requirement sounds simple.

Create an incident in one system, and create a corresponding record in the other.

Update one, and synchronize the change.

Then the actual questions begin.

What happens if the destination API is unavailable?

What happens if the same update is processed twice?

How do you prevent two systems from endlessly triggering updates in each other?

What happens when the priority models differ?

How do attachments move?

How do you preserve the relationship between records?

How do you troubleshoot a synchronization failure without creating inconsistent data?

Suddenly, the interesting part isn't the HTTP request.

It's the behavior of the entire integration.

Working with ServiceNow and GLPI gave me a closer look at those problems.

I had to think about field mappings, correlation identifiers, business rules, comments, attachments, and how the two systems should behave when records changed.

The experience also made me appreciate testing.

Not just checking whether an API returned 200 OK, but following an incident through the workflow and verifying that the resulting records were correct.

A successful API call doesn't necessarily mean a successful business operation.

That distinction has stayed with me.

I Became More Interested in the Decisions Behind the Code

Earlier, I enjoyed conversations about technology choices.

I still do.

But I've become less interested in declaring one technology better than another.

A system doesn't become well designed simply because it uses Kubernetes.

A database doesn't become the correct choice because it performs well in a benchmark.

An architecture doesn't become scalable because someone divided it into microservices.

Every choice exists within constraints.

Budget.

Team experience.

Time.

Operational requirements.

Existing infrastructure.

Customer expectations.

Maintenance.

I've gradually become more interested in understanding those constraints before proposing solutions.

Sometimes a managed service is worth the additional cost because the team doesn't need to operate another component.

Sometimes a simple scheduled job is enough.

Sometimes introducing another service solves a real problem.

Sometimes it just creates another deployment pipeline, another monitoring requirement, and another thing that can fail.

I'm still learning to recognize the difference.

I don't think architectural judgment arrives after earning a certification or receiving a particular job title.

It develops when you start paying attention to the consequences of decisions.

Especially the consequences that appear long after the original code was written.

Certifications Were Useful. They Weren't the Destination.

Over the past year, I spent a considerable amount of time studying Azure.

Administration.

Development.

Architecture.

DevOps.

AI services.

I earned multiple Microsoft certifications, including Azure Solutions Architect Expert and DevOps Engineer Expert.

I'm glad I pursued them.

Preparing for those examinations forced me to explore areas I might otherwise have ignored.

Networking configurations.

Identity and access management.

High availability.

Disaster recovery.

Governance.

Deployment strategies.

Monitoring.

Cost management.

But certifications also have a limitation.

Passing an architecture examination doesn't mean you've experienced every architectural failure.

Knowing how a service works doesn't mean you've operated it during an incident.

Understanding disaster recovery concepts doesn't mean you've successfully recovered a failed production system.

An examination can validate knowledge.

Experience tests how you use it.

I've come to see certifications as a structured way to identify what I should learn, rather than proof that I've finished learning it.

The certificate is useful.

What matters more is what I can do with the knowledge afterward.

Teaching Changed the Way I Learned

One of the most rewarding parts of my journey has happened outside my regular engineering work.

Technical talks.

Workshops.

Mentoring.

Community events.

Classrooms.

I've had opportunities to speak about cloud computing, AI, development, and other engineering topics to audiences with very different backgrounds.

Preparing a technical session is a surprisingly effective way to discover what you don't understand.

It's easy to believe you know a subject when you're reading documentation or following a tutorial.

It's much harder when you need to explain it to someone who has never encountered it before.

A student might ask a basic question that exposes an assumption you've been making for years.

A developer might ask about an implementation detail you hadn't considered.

Someone else might approach the entire problem from a different direction.

I've learned to appreciate those moments.

They're occasionally uncomfortable.

But they're useful.

I also stopped believing that teaching requires knowing everything.

It requires knowing what you're explaining, being prepared, and being willing to admit when you don't know something.

I think that last part is particularly important.

There's nothing wrong with saying, "I don't know. I'll have to look into that."

I'd rather give someone an honest answer than a confident explanation I can't defend.

Writing a Book Was a Different Challenge

At some point, I decided to write Practical AI for Platform and Cloud Engineers.

The motivation was straightforward.

As AI became more prominent in engineering discussions, I noticed that a lot of educational material focused either on model development or high-level business applications.

I wanted to approach the subject from the perspective of engineers responsible for building and operating platforms.

How does AI fit into existing infrastructure?

What changes when an application starts using large language models?

Where do retrieval systems belong?

How do we think about security, observability, deployment, and operational responsibility?

Writing the book forced me to organize ideas that had previously existed as scattered notes, experiments, and explanations.

It was also a reminder of how difficult clear writing can be.

A paragraph can sound perfectly reasonable until you read it again and realize it doesn't actually explain anything.

A technical explanation can be accurate and still be unnecessarily complicated.

Sometimes removing three paragraphs improves a chapter more than adding another five.

I found myself asking the same questions I ask when reviewing software.

Does this need to exist?

Is this abstraction helping?

Can someone unfamiliar with the subject understand it?

Writing and engineering have more in common than I expected.

Both require deciding what to leave out.

I Still Like Building Things That Have Nothing to Do With Work

Not everything I've learned has come from a computer.

I spend time maintaining aquariums, breeding fish, growing water lilies, and experimenting with small aquatic ecosystems.

My first betta breeding attempt didn't go as planned.

The fish spawned.

The eggs hatched.

The fry became free-swimming.

And eventually, I lost them.

I had prepared for breeding, but I hadn't prepared a sufficiently reliable supply of microscopic live food for the fry.

It was disappointing.

It also made me realize how much I had focused on the exciting part of the process while underestimating what would be required afterward.

I could have watched another dozen breeding videos and still missed something.

Actually attempting it made the problem impossible to ignore.

Growing water lilies has been a different kind of experience.

There isn't a progress bar telling me when the next flower will appear.

Sometimes a plant grows quickly.

Sometimes it seems to do nothing for weeks.

Sometimes the conditions appear right and the plant still behaves differently than expected.

I have to observe, make small adjustments, and wait.

I enjoy that.

Not every hobby needs to improve my engineering skills or teach me a professional lesson.

Sometimes it's enough to walk outside in the morning and find a flower that wasn't open yesterday.

I've Become More Comfortable Not Knowing

One thing I've noticed about myself is that I used to feel a stronger need to have answers.

If someone mentioned a technology I hadn't worked with, I wanted to learn it immediately.

If I encountered an unfamiliar architecture, I wanted to understand every component.

If there was a new certification or framework, I wondered whether I should pursue it.

That curiosity is still there.

But I'm becoming more selective about where I direct it.

There will always be another framework.

Another cloud service.

Another programming language.

Another model.

Another certification.

It's impossible to know everything, and trying to keep up with everything can become its own distraction.

I'm learning that being a capable engineer doesn't require having an immediate opinion on every technology.

Sometimes it means knowing enough to ask the right questions.

Sometimes it means researching before making a decision.

Sometimes it means acknowledging that someone else understands a particular problem better than I do.

And sometimes it means deciding that I don't need to learn something right now.

That's been a useful change.

Leaving Familiar Ground

October 2026 marks another transition for me.

After starting my full-time career at Kyndryl, I'm preparing to move into a customer engineering role at Niveus Solutions.

Changing organizations is a strange experience.

You spend time learning how a company works.

You become familiar with its systems, processes, and people.

You gradually understand things that were confusing when you first joined.

Then you decide to leave.

Some of that knowledge will be useful in the next role.

Some of it won't.

I'll have new systems to understand, new expectations to meet, and new areas where I'll be inexperienced again.

I don't expect the transition to be effortless.

There's a lot I still need to learn about customer engineering, especially the parts that go beyond technical implementation.

Understanding a customer's actual problem.

Evaluating whether a proposed solution makes sense for their environment.

Explaining trade-offs clearly.

Building trust.

Being able to say when something isn't a good idea.

Those are skills I want to develop.

I'm looking forward to the work, but I'm also aware that a new role doesn't automatically make me a better engineer.

What matters is what I learn while doing it.

The Engineer I Was

When I look back at the engineer I was during college, I don't see someone who was wrong about everything.

I see someone who was excited about technology.

Someone who enjoyed experimenting.

Someone who wanted to build useful things and understand how they worked.

I still recognize that person.

The difference is that I now have a slightly better appreciation for everything surrounding the code.

The customer who needs the application.

The engineer who maintains it.

The team responsible for deploying it.

The person responding when something fails.

The constraints that shaped its design.

The decisions that will remain long after the original implementation is forgotten.

I haven't stopped caring about code.

I've started caring more about what happens because of it.

The Engineer I'm Becoming

I don't have a perfect picture of where my career will be five years from now.

I know the areas that interest me.

Backend engineering.

Cloud architecture.

Platform engineering.

Distributed systems.

AI systems.

But I don't want to define my entire career by a list of technologies.

Technologies change too quickly for that.

I'd rather become someone who can enter an unfamiliar environment, understand the problem, evaluate the constraints, and help build something that works.

Someone who can explain a complicated system without making it sound more complicated than it is.

Someone who knows when to build and when not to.

Someone who can defend a technical decision but is also willing to change it when the evidence changes.

Someone other engineers can depend on.

I still have a long way to go.

And I think that's worth acknowledging.

What Comes Next

I'm writing this at an interesting point in my career.

I've completed my first chapter of full-time professional engineering.

I've worked on systems I enjoyed, encountered problems I didn't expect, met people who taught me things, and made decisions I'd approach differently today.

I've also had opportunities outside work that I didn't imagine when I first started programming.

Speaking at technical events.

Mentoring students.

Writing a book.

Building personal projects.

Travelling.

Experimenting with hobbies that have nothing to do with software.

I don't know exactly how all of these experiences will influence the next few years.

But I know I want to keep doing them.

I want to continue building software.

I want to work on more difficult engineering problems.

I want to understand cloud platforms beyond their documentation.

I want to become better at designing systems and explaining decisions.

I want to continue teaching and writing.

And I want to keep enough time for the things I enjoy outside work.

I don't think those interests compete with one another.

They're simply different parts of my life.

Final Thoughts

When I started programming, I was excited by the possibility of making a computer do something.

That excitement hasn't disappeared.

I still enjoy seeing an application work for the first time.

I still enjoy solving a difficult bug.

I still enjoy learning something unfamiliar and eventually understanding it.

What has changed is my idea of progress.

A year ago, I might have measured it through the number of technologies I knew, projects I completed, or certifications I earned.

Those things still have value.

But they aren't the whole picture anymore.

Progress also means becoming more patient with difficult problems.

Being willing to question my own decisions.

Learning to communicate more clearly.

Understanding that other people will have to live with the systems I build.

And recognizing that sometimes the most useful thing I can contribute isn't another piece of code.

It's a better question.

I don't think I've become the engineer I imagined I would be when I started.

I'm still figuring that out.

But I like the direction I'm heading.

And for now, that's enough.