My approach to technology is built on curiosity and patience. What started with a “How does this work?” phase has developed into a professional focus on System Integration and building infrastructure that actually lasts.
I don’t believe in “quick fixes” that break a week later. I believe in the quiet satisfaction of a well-planned system that runs exactly as intended.
From Frontend to Systems
I started with the absolute basics of frontend development. It gave me a great perspective on the user side of tech, but I quickly realized my real interest was in the “engine” powering the interface. I wanted to understand the logic, the servers, and the networks sitting underneath.
My first real training ground was a Raspberry Pi Model B rev 2.0. It wasn’t about complex enterprise racks yet; it was about the fundamentals.
Managing home servers and troubleshooting Linux distributions taught me the most important skill I have: methodical problem solving. I learned to isolate variables, stay patient, and ask the right technical questions when things go south.
Architecture & Maintenance
As I moved into my professional training as an IT Specialist for System Integration, my mindset shifted from “fixing” to architecting. If a system is designed well from the start, maintenance becomes a breeze rather than a headache.
I prioritize a “plan twice, deploy once” workflow. A solid blueprint saves hours of reactive debugging later.
My core technical interests include:
- Networking: OSI model, IPv4, and IPv6 to ensure data moves efficiently.
- Data Integrity: Using SQL to manage databases that are clean and performant.
- Automation: Following the rule that if a task is repetitive, it should be scripted to save time and reduce human error.
Second Brain
To stay organized in a fast-paced field, I rely on Logseq. I document my entire learning journey and technical workflows using Markdown.
The reason I stick to Markdown is simple: independence. Unlike proprietary formats, Markdown is plain text. It is future-proof; if the software I use today disappears, my notes remain readable by any basic text editor. It is lightweight, allows for fast version-control via Git, and keeps the focus entirely on the information rather than the formatting.
My knowledge base is version-controlled and synced across my workspaces. This means if I solve a complex problem once, the solution is archived and ready for me whenever I need it again. It’s about building a reliable, searchable library of my own experiences.
Infrastructure as Code (IaC)
The real “level up” in my work was adopting (IaC). By defining environments through code, I make them repeatable, documented, and professional. It removes the guesswork and ensures that the infrastructure is as clean as the code that runs it.
Beyond efficiency, IaC is the backbone of reliable Disaster Recovery. In the modern landscape, I can’t imagine a medium-to-large-scale client running their infrastructure any other way. If you aren’t running your infra as code, you don’t truly have a recovery plan you can trust. It turns a catastrophic server failure into a “re-run script” scenario.
Philosophy
To teach is to truly understand. I value sharing knowledge. I’ve found that breaking down a complex system to explain it to someone else is the best way to find the gaps in my own understanding.
- Foundations First: Simple code and clean infrastructure are easier to maintain and more secure.
- Stay Adaptable: In technology, being willing to learn is just as important as what you already know.
- If it’s not documented, it’s not finished: I aim for every project to be clear enough for the next person to understand.
Looking Ahead
I’m currently focused on scaling my skills in automation and IaC. My goal is to keep building and maintaining infrastructure that is smart, secure, and reliable.
