DC, Bigger Cities, and What I'm Starting to Understand About Opportunity

Washington DC hit differently than I expected.

I went out there for the National Security Hackathon and came back thinking about a lot more than just the event itself. DC is a clean, walkable city with a certain kind of weight to it. History is everywhere. The architecture, the monuments, the energy of the people moving through it — you feel it. And the crowd that shows up to events like that hackathon reflects the city: policy people, government folks, engineers, researchers. People who are doing serious work and take it seriously.

It was a genuinely great experience. I met a lot of people and connected with mentors I would not have crossed paths with otherwise. But one thing kept getting louder the longer I was there.

There Are More Opportunities in Bigger Cities Than I've Been Letting Myself Believe

This wasn't a new idea. I had heard it before. But there's a difference between hearing something and having someone look you in the eye and say it directly.

I met people at the hackathon who had traveled from San Francisco, from New York, from all along the coasts. People who work in contracting, in policy, in tech. And more than one of them told me the same thing: if your goal right now is to network, build credibility, and put yourself in the right rooms — you need to be where the rooms are.

That landed. Not in a way that made me feel behind, but in a way that made me feel honest about what I want and what it will take to get there. I am still figuring out the timeline, but I know that staying comfortable is not the same as staying strategic.

Coding Is Not a Special Skill Anymore — And That Is Fine

Something surprised me during the hackathon that I am still processing.

I was building alongside people who are not engineers. Not even close. And they were building real things. Functional things. Using AI tools to write code, string together logic, and ship something that actually worked. That is genuinely impressive in a way that I want to be honest about.

But here is what I also noticed: they did not fully understand what they were building.

They could type a prompt and get an output that worked. But they could not tell you why it worked, what would break it at scale, or what the tradeoffs were in the design. System design, architecture decisions, the invisible constraints that experienced engineers hold in their heads — that knowledge was not there.

This is not a criticism. It is an observation.

Coding is more accessible than it has ever been. That is a good thing. Just like anyone can make art with the right tools, anyone can now produce functional software. It does not lose its value. But it does shift where the real value lives — and that is in judgment, not just execution.

I had a conversation on the way back with someone from John Deere and someone from Meta. Neither of them cared about your stack preferences or how many projects you had on GitHub. They cared about whether you could understand the problem, make good decisions under pressure, and get the thing done correctly. That is what they are hiring for. That is what they are paying for.

Understanding the tradeoffs is the skill. The typing is just the tool.

The Project: A Cybersecurity Copilot Built in Two Days

The hackathon was a short sprint, and we built something real.

Working with a team of non-engineers, I led the technical side of a cybersecurity copilot designed to help analysts work faster and make better decisions. Two days. A team that had never shipped code before. And we got it done.

---

Demo Video: Watch the demo

GitHub Repo: View the repo

---

Building under that kind of constraint with people from completely different backgrounds taught me a lot. It forced me to communicate clearly, break down complexity quickly, and ship something that actually worked — not just something that was technically interesting.

That is the kind of experience you do not get from building alone.

One thing I will say, and I think this is specific to hackathons depending on who is judging: UI matters more than I expected. Practical, well-engineered solutions do not always win. Judges respond to what looks good in a demo. I learned this firsthand at this one and I suspect it holds at others too. It is not a criticism, just something worth knowing going in. If you are building something real and technical, make sure it also looks the part when you are standing in front of a panel.

What I'm Taking Back

I came into the hackathon hoping to build something cool and meet some interesting people. Both happened. But what I didn't expect was how much it would clarify things.

Bigger cities. More rooms. More chances to meet people who are doing things at a different level.

I know where I want to go. DC made that clearer.