About me
I'm a 5th-semester Elektroteknologi (B.Eng. in Electrical Engineering) student at DTU. Most of what I know about electronics comes from building things that had to actually work: firmware that runs unattended for months, boards that carry real current, and tools I built because the ones I wanted didn't exist.
The work I want
The role I'm after is hardware troubleshooting. Hand me something that should work and doesn't — a board, an instrument, a protocol that won't talk — and finding out why is the part I genuinely love. Problem-solving is the skill I lean on hardest and the one I'm best at; most of the projects on this site exist because I chased a fault until it made sense. If your team has hardware that needs someone stubborn and methodical to debug it, that's exactly the work I want to be doing.
The fabrication line
The part of my setup people remember: I can go from a KiCad schematic to a soldered, reflowed PCB without leaving the building. Boards are etched on an xTool F1 Ultra fiber laser or milled on a Roland SRM-20 — driven by a CAM tool I wrote myself — and reflowed on a hotplate I designed from scratch. Iteration time from schematic change to tested board is measured in hours, not weeks. I've documented the whole workflow as a guide other DTU students use.
How I work
I write down what went wrong. Every project page on this site has a section on failures and how they were diagnosed, because the debugging is where the actual engineering happens — scope captures, protocol dumps, and boards that behaved badly until they didn't. I'd rather show a fault I found with a logic analyzer than an adjective.
Working with AI
I treat directing AI as a core engineering skill — arguably the one compounding fastest right now. The hardware, the debugging, and the design decisions are hands-on and mine. But for the software-heavy work — building this site, the heavy-duty Python behind tools like Componentbot — I don't hand-write it. I orchestrate it. I bring the requirements, the architecture, and the standards; I know what "done right" looks like and where the best-practice lines are; and I direct an AI to implement against that.
What makes it trustworthy is verification. I have it write tests the whole way through and prove each piece works before anything new is built on top — the same discipline as the rest of this site: nothing moves forward until it's checked. Knowing exactly what to build, to what standard, and how to keep an AI honest with tests is, to me, precisely the skill this decade rewards — and I also build AI into what I ship, from Componentbot to SPICEPilot and the Claude-backed features in my home-lab tools.
Beyond the bench
I run a small home lab (Home Assistant OS, Proxmox, self-hosted services on Raspberry Pis and repurposed laptops) that doubles as a deployment target for my own firmware and software. 3D printing (Prusa MK2S), fiber laser, and CNC milling cover the mechanical side.
Practical details
- Seeking: engineering internship (praktik) from late January 2027, and student jobs.
- Based in Kgs. Lyngby / Copenhagen area, Denmark.
- Danish native speaker, fluent English.
- Contact: mads28122001@hotmail.dk · GitHub · LinkedIn