About me
I'm studying Cloud & Cybersecurity at Thomas More in Belgium, within the broader Electronics - ICT program. I chose Electronics - ICT because I wanted a practical study path where I could build, test, and understand real systems instead of only learning theory. My work is becoming more infrastructure-oriented: cloud, Linux, networking, and security.
Over time, that direction became clearer through coursework, difficult labs, practical mistakes, and personal projects. I focus on networking, Linux, server configuration, security, and cloud deployments. I'm most engaged when I can inspect a system directly, change it, and see the effect.
My learning style is trial and failure. I build first, let things break, read errors until I understand the root cause, then rebuild with better assumptions. It's slower at the start, but the understanding lasts. This portfolio reflects that process and how my thinking has evolved over time.
SKIL2 and other team projects gave me practical experience with shared systems, coordinated infrastructure work, and cross-component debugging. They also taught me that collaboration works best when tasks are clearly divided, assumptions are aligned early, and decisions are explained step by step.
Long-term, I want to work in cloud, systems, or security engineering in an international environment. Belgium is where I'm building the base: deeper Linux skills, stronger networking knowledge, better deployment habits, and more practical security understanding.
The progression
My first real entry point was web design and basic programming. HTML, CSS, Bootstrap, page structure, responsive layouts, and early programming logic gave me a practical base to build from. It was not the final direction yet, but it taught me how small decisions in structure and code affect how a project behaves when you try to make it real.
Windows Server and networking were the first areas where infrastructure started to feel connected instead of separate. Active Directory, DNS, DHCP, server roles, and basic network configuration showed me that services only make sense when you understand how they depend on each other. A working setup was never just one correct setting; it was clients, servers, names, addresses, and permissions lining up.
Linux and security courses made the work more serious. Permissions, services, logs, network services, and administration tasks forced me to slow down and read what the system was actually doing. Web application security added another layer: Burp Suite, HTTP manipulation, SQLi, XSS, CSRF, command injection, validation, and trust boundaries showed how small assumptions can become real weaknesses.
Personal projects and coursework pushed me toward cloud and deployment work. AWS, EC2, S3, CloudFront, Route 53, Nginx, HTTPS, SSH, hosting, and DNS/CDN configuration made it clear that deployment is not just uploading files. Real systems involve certificates, ports, processes, service restarts, broken assumptions, and careful debugging before anything feels stable.
My current direction is cloud, systems, and security engineering. Docker and containerization are the next practical focus, alongside stronger Linux and networking depth. After that, I want to build more confidence with Kubernetes, Terraform, Ansible, CI/CD, and monitoring. The goal is not to rush into expert language, but to keep building technical judgment through systems that actually run.
Outside the terminal
I train consistently and treat it as long-term work, not short bursts. I track progress, adjust when needed, and stay with the process. That same approach helps me solve technical problems without rushing to random fixes.
I prefer building over only studying theory. Getting systems running in a real environment teaches more than reading about them. Most of my progress comes from testing, breaking, and fixing until the setup is stable.
I'm interested in how people think and make decisions, especially in teamwork and pressure moments. You can often predict project issues by how people communicate under stress. Reading that well helps keep technical work clear and coordinated.
Technical profile
Capability areas, not tool lists. Honest about what's solid versus early-stage.
Honest assessment
Being clear about current gaps is part of how I approach learning. These are areas I know I haven't developed enough yet — and where I have a specific plan to improve.
I currently configure infrastructure manually. Terraform and Ansible are the next step to make provisioning reproducible and auditable. Plan: rebuild the AWS setup as a Terraform project with proper state management.
I understand Kubernetes architecture conceptually but haven't deployed anything meaningful with it yet. Plan: work through a structured hands-on course and deploy a multi-service application from scratch.
I have built container image pipelines, but not a full production deployment pipeline end-to-end yet. Plan: add stronger GitHub Actions deployment checks to my personal projects so releases are triggered and validated automatically, not manually.
My Bash scripting is functional but not systematic. I want to write automation that handles edge cases, logs properly, and fails gracefully — not just scripts that work under the happy path.
Direction
I want to grow into cloud and systems engineering work that is bigger than a classroom project: real infrastructure, real users, real pressure.
The target is simple: become the kind of engineer people trust when the system has to keep running.
Belgium is where I'm building the base. International work is the direction. The next step is more hands-on depth in Kubernetes, CI/CD, automation, and recovery.