Why I Rebuilt This Site (and What I’ll Be Using It For)

For a long time, my personal website didn’t reflect how I actually work. It had become outdated, unfocused, and disconnected from the kinds of problems I spend most of my time thinking about.

This rebuild is a reset.

The purpose of this site is straightforward: to serve as a clear, honest companion to my resume and GitHub. GitHub shows what I build. This space is for context — the thinking, tradeoffs, and observations that sit behind the code, systems, and decisions.

Much of my work lives at the intersection of education, cybersecurity, automation, and infrastructure. In those spaces, clean theory rarely survives first contact with reality. People, constraints, timelines, and imperfect systems shape outcomes just as much as technical choices do. This site gives me room to document that reality.

A place for reflection, not promotion

Some of what I write here will be reflective. Over time, patterns emerge when you work across systems long enough — where things tend to fail, what gets ignored, and which decisions quietly matter the most. Writing is a way to slow down and examine those patterns rather than rushing past them.

I’m interested in the why behind systems as much as the how:
Why a design choice felt right at the time but aged poorly.
Why a technically “correct” solution failed once people were involved.
Why certain approaches scale and others don’t.

This isn’t about personal branding or hot takes. It’s closer to professional journaling — capturing observations while they’re still fresh.

A record of real work

Alongside that reflection, this space will also include practical, technical writing.

You’ll find:

• Walkthroughs and how-tos from projects I’m building
• Notes on automation workflows, infrastructure setups, and security decisions
• Documentation-style posts meant to be useful to others, not just polished after the fact

In many cases, these posts will exist because something was hard, confusing, or unexpectedly fragile — and writing it down made the system better.

Why write at all?

Writing forces clarity. If I can’t explain how a system works, where it breaks, or why a particular tradeoff was made, then I probably don’t understand it as well as I think I do.

This process sharpens decision-making and creates artifacts that outlive any single project. It’s also a way to make technical work more accessible, especially in environments where not everyone shares the same background or vocabulary.

How this fits with the rest of the site

The structure here is intentional:

• Projects show what I’ve built or am actively building
• Writing captures the thinking, lessons, and documentation behind that work
• Process and metrics provide context around how I operate and the scale I’ve worked at

Together, they tell a more complete story than code or a resume alone.

What’s next

Posts here will vary in tone and depth. Some will be technical and procedural. Others will be reflective or exploratory. All of them will be grounded in real work rather than abstract trends.

If something here resonates or sparks a conversation, I’m always open to connecting.