A few months ago, I decided to put bug bounty hunting on the back burner and focus on something much closer to the work I actually enjoy: IT infrastructure and networking.
That decision created a new question.
If I want to become a better infrastructure engineer, what am I actually going to do about it?
The answer was sitting right in front of me.
Build.
I’ve had a homelab for a while, but I’m changing how I use it. Instead of collecting equipment and following tutorials, I’m treating the lab as a place to deliberately build the skills I’m trying to develop.
The goal isn’t to recreate an enterprise environment perfectly. The goal is to encounter the same kinds of problems an infrastructure engineer encounters:
How does routing behave when things change?
What happens when a link fails?
How do you segment a network properly, and build services on top of it?
And, probably most importantly, how do you troubleshoot it when you’ve broken it?
Why document it?
This isn’t just about learning something and moving on. I want a record of the process: the configuration, the mistakes, the things that didn’t work, the troubleshooting, the diagrams — and eventually, the lessons I’d actually take into a production environment.
I’ve spent years working in IT, but there’s a difference between having experience and deliberately building depth in a particular area.
Infrastructure and networking are the lane. The homelab is the training ground.

