Why I'm Diving Into Software Engineering

My path into tech has not been a straight line, and that is exactly why this shift matters so much to me.

I served in the U.S. Marine Corps, primarily as an infantryman, while also training in Information Assurance and communication systems. Later, I earned a degree in Secondary Education with an English focus. Eventually, I landed in Application Support, and that turned out to be the pivot point.

Application Support put me close to software in a different way. It taught me how systems behave in the real world: where they break, where users get stuck, where workflows create friction, and where thoughtful design actually matters. It made something click for me. I realized I did not just want to work around software, troubleshoot it, or support it from the edges. I wanted to build it.

For a while, I thought of my interest in tech as a collection of separate threads: programming, problem-solving, systems, security, automation, and the satisfaction of making something work. Over time, those threads started to connect. What I realized is simple: I want to build applications and tools that solve real problems, feel good to use, and make someone's day a little easier, faster, or clearer. That is the direction I am leaning into now, and it is why I'm diving deeper into software engineering.

Why Software Engineering

What draws me to software engineering is that it turns ideas into real, usable things.

An idea by itself is interesting. A rough prototype is encouraging. But a finished piece of software - something a person can open, understand, and use - feels different. It is concrete. It has shape. It does something.

That matters to me.

I like the process of taking a problem, breaking it down, designing a solution, building it piece by piece, and refining it until it becomes a product instead of just an experiment. Software engineering gives me a path to do exactly that.

It is not only about writing code. It is about thinking clearly, building deliberately, and creating systems that work for actual people.

I Want to Build for Users

One of my most significant realizations is that I do not want to build software just to say I built it. I want to build software that people want to use.

That means software that is:

• Useful instead of impressive for its own sake
• Clear instead of confusing
• Reliable instead of fragile
• Thoughtful instead of bloated
• Designed with the user in mind from the beginning

There is a huge difference between making something technically functional and making something genuinely usable. I'm interested in closing that gap.

I care about the backend systems, the logic, the architecture, and the infrastructure that make software work. But I also care about the expeience on the other side - the part the user actually sees, touches, and remembers.

I want to build software where both sides matter.

Why This Feels Like the Right Direction

What makes software engineering feel like the right path for me is that it combines several things I care about at once

It gives me room to:

• Solve meaningful problems
• Keep learning at a deep level
• Build across multiple layers of a product
• Improve both technical and creative skills
• Create work I can point to and say, "I made that"

I'm especially drawn to development work that goes beyond isolated exercises and moves toward complete applications: tools, platforms, systems, and products that have a real use case.

I do not want to stay at the level of theory forever. I want to turn knowledge into projects, and projects into proof.

That is a big part of what this shift is about for me. It is a decision to stop treating development like a side interest and start treating it like the work I want to grow into seriously.

What I Want to Build

I'm interested in building software that is practical, well-structured, and worth returning to.

That includes things like:

• Web applications that solve real world problems for real users
• Backend systems that are secure, reliable, and scalable
• Tools that simplify workflows and reduce friction
• Projects that connect strong engineering with good user experience
• Creative software of my own, including the possibility of building a small retro-style game

That last part matters to me more than it might have a year or more ago. In Build Orders and Build Logs - a post that should be live soon - I explore why older strategy games still feel so compelling to me and why trying to build something in that spirit feels worth taking seriously. Even though that kind of project would be very different from a web app or backend service, it comes from the same place: I want to make software that feels coherent, intentional, and satisfying to use.

That thread runs through some of my othe work too. A project like Trudvang Character Creator is niche, but it reflects the same instinct - take something complicated, structure it well, and turn it into an experience that feels clearer and more usable. And in Continuing the Journey, I wrote about moving from supporting software to building it. This is part of what I meant.

I like the idea of building software that people come back to because it genuinely helps them, whether that means solving a practical problem, supporting a specific community, or creating an experience that is simply tight, thoughtful, and worth spending time with.

Not everything I build will meet that standard right away. Some projects will be rough. Some will be learning experiences. Some will mainly teach me what to do differently next time. But that is still part of the process. The goal is not perfection on the first attempt. The goal is to keep building, keep learning, and keep moving toward software that is genuinely worth using.

What This Blog Will Be

This blog is still part of that process, but the focus feels sharper now.

It is where I want to document not just a broad shift into software engineering, but the actual work of becoming the kind of developer I want to be. That means writing about the projects I'm building, the technical decisions I'm making, the problems I'm getting stuck on, and the skills I'm deliberately trying to strengthen.

Right now, a big part of that work is structured learning. I've been using Hyperskill and Boot.dev as places where I can keep building real momentum, especially in the areas I know will matter for what comes next. It gives me a way to keep sharpening my programming fundamentals, spend more time with Java, C++, and Python, and keep turning study into practice instead of letting it stay abstract.

The next major step after that is WGU. I'm preparing to start the accelerated Bachelor/Master of Science in Software Engineering path there with a strong amount of transfer credit already in place, which means the road ahead is less about starting from scratch and more about moving intentionally into the technical core: software engineering, Java, backend development, architecture, testing, and cloud-oriented work.

So this blog will further track that version of the journey more clearly.

Some posts will be build logs and project writeups, and some will be notes from the learning process itself, i.e., what Hyperskill is helping me tighten up, what WGU is pushing me to learn next, and how those things connect to the kind of engineer I'm trying to become. And some will still be reflections, but I want those reflections to stay tied to real work.

At the center of all of it is a more concrete goal now:

To keep building the skills, habits, and projects that move me toward becoming a software engineer who can build useful, well-structured tools and applications for people.

That is the direction. That is the next stage. And, as ever, that is what this blog is here to document.