Deny First.
Verify Always.
Every engineer eventually reaches the point where the right answer is no.
Not because you can’t do it — you probably can. But because saying yes to everything is how complexity compounds, how scope creeps, and how good infrastructure quietly becomes someone else’s problem at 2am. Implicit deny isn’t just a firewall rule. It’s a discipline. Start with no. Build toward yes only when it’s earned.
That’s the philosophy this blog runs on.
Infrastructure and security practitioner with 20 years across the stack — a decade as a network engineer, a decade as a systems engineer and architect. Currently focused on large-scale virtualization, cybersecurity, and building AI-capable infrastructure in constrained and air-gapped environments.
Institutional Knowledge Doesn’t Transfer Itself
Something is happening in enterprise IT that nobody is talking about loudly enough. The engineers who built their careers on deep, hard-won infrastructure knowledge — the ones who’ve seen three generations of hypervisors, who remember when BGP was something you learned from a Cisco press book and a lab full of routers — are aging out of the workforce. And the institutional knowledge they carry isn’t being systematically transferred to the people coming up behind them.
AI is accelerating this. Junior engineers are increasingly reaching for a chat interface instead of understanding why something works the way it does. That’s not a criticism — it’s a structural shift. But it means the gap between surface-level capability and genuine depth is widening fast.
Implicit Deny exists to push back on that. Not with textbook content or vendor documentation rewrites — there’s enough of that. With the kind of perspective you only get from having made the mistakes, seen the edge cases, and spent enough time in production environments to know what actually matters. Two decades across networking and systems infrastructure gives you opinions. This blog is where those go.
The Human Behind the Terminal
I’ve spent over seven years living in Korea across different stretches of my life — enough time to develop a genuine love for the culture, the food, and the particular brand of organized chaos that makes Seoul one of the most interesting cities on earth. Budae jjigae at midnight is a perfectly valid life choice.
When I’m not working, I’m usually in the home lab. My current obsession is self-hosting everything — the goal being to progressively replace every cloud service I pay for with something I run and control myself. It’s part principle, part curiosity, and part the kind of project that never quite finishes, which is honestly the appeal.
What Gets Published Here
Infrastructure deep dives. Security takes that don’t pull punches. Honest assessments of the vendor landscape — including when the answer is to walk away. Home lab builds and self-hosting guides for people who want to actually understand what they’re running. And occasionally, an opinion piece when something in the industry needs saying plainly.
If you’re a junior engineer trying to build real depth: this is written for you. If you’re a seasoned practitioner who’s tired of surface-level content: also for you. If you’re a vendor hoping for favorable coverage in exchange for nothing: implicit deny.