How I Rebuilt My Technical Career — In Public, With Evidence

I've worked in IT for 19 years.

Sysadmin. Support. Infrastructure. Forensics. SOC. The kind of career that crosses every layer of the stack because at some point, something in every layer needed fixing and I was the person available to fix it.

Then I was made redundant.

I had a choice that I suspect a lot of people in that position face: retrain quietly and reappear with a new set of certifications, or build everything in the open and let the work speak.

I chose the second option. Here's why, and what it's looked like in practice.

---

Why "in public" matters

Certifications prove you studied. A portfolio proves you built something.

That's not a slight on certifications — I have them, I value them, they open doors. But a cert tells a hiring manager you passed an exam. A GitHub repository with a real deployment, documented decisions, and an honest post-mortem tells them something different. It tells them how you think.

Building in public creates accountability that studying privately doesn't. When you know someone might read it, you document more carefully. You explain your reasoning. You write down what broke and why. That habit — of treating your own work as something worth examining — compounds over time.

It also makes you discoverable in a way that a CV alone doesn't. A CV is a claim. A portfolio is evidence. Those are different conversations.

---

What it's actually looked like

Not glamorous. Not a viral moment. A series of projects, each one published with the architecture, the decisions, what went wrong, and what I'd do differently.

Mini-finance: a containerised application, Ansible-deployed, with a 403 I had to debug live and write about honestly.

AWS three-tier deployment: a full production-grade infrastructure build — VPC, load balancer, auto-scaling, RDS — documented end to end.

EpicBook: a multi-environment deployment pipeline with role-based Ansible, idempotency testing, and a writeup of what production-readiness actually requires versus what most tutorials show you.

Alongside that, a blog. Not thought leadership. A learning journal — the place where I work through what I just built, what the harder parts were, and what the gap is between how something is taught and how it behaves in production. The debugging story is more useful than the working code. I've tried to write both.

---

What changed

The conversation shifts when you can say "here's the repo" instead of "I have experience with."

I noticed it in how people responded to my posts. Technical people engage differently with work they can actually inspect. They ask specific questions. They push back. They contribute. That's a different quality of interaction than "great post" on a credentials update.

I also noticed it in how I talk about my work. When everything is documented, you stop describing what you did in vague terms. You stop saying "I worked on infrastructure automation" and start saying "here's the problem, here's what I built, here's where it didn't work the first time." That precision is what separates someone who did something from someone who understands what they did.

---

What the portfolio approach actually requires

Publish the thing that didn't work the first time. Write the post that explains what the tutorial skipped. Document the decision you made and the one you wish you'd made instead. That material is more credible than a polished success story because it's real — and anyone who hires engineers knows the difference between someone performing competence and someone demonstrating it.

The standard isn't perfection. It's honesty about the work and rigour about the process.

---

I'm still building.

The portfolio is live. The work is on record. The transition is in progress and visible — across cloud infrastructure, DevSecOps, and SOC engineering, which is where my background and the work I've been doing both point.

Nineteen years gave me context. The last year gave me proof.

Both matter. The proof is what people can see.