This blog is not a polished magazine. It is my personal tech notebook — a place to capture what I learn, remember why I built things, and keep a clear trail of my experiences.

Who I am

I am an electronic engineer with more than 15 years of software development experience across the full stack of embedded and systems work. My background starts at bare metal and microcontrollers, extends through embedded Linux and embedded systems, and also includes desktop application development and practical infrastructure work.

I build, experiment, and trust tests more than assumptions. Over the years I have worked on firmware, device communication, board-level debugging, low-level drivers, desktop tools, and the small operational details that keep systems alive and maintainable. I write this to remember the journey and to leave a record of what worked, what failed, and why I chose a certain path.

My usual field includes embedded software, electronics-focused product development, Linux-based devices, system integration, automation, and engineering troubleshooting. I work comfortably with C, C++, Qt, VS Code, Jenkins, Docker, CAN, embedded toolchains such as IAR and Keil, and the practical workflows around building, testing, flashing, debugging, and maintaining real systems.

My goal

This space is meant to be:

  • a memory bank for future me
  • a reference for practical engineering decisions
  • a quick way to explain how my setup works
  • a place where internet users can find useful notes or solutions

I want this blog to be real, honest, and helpful. If you read it and get something out of it, that is already a win.

Why this exists

I build things to learn, to improve, and to make systems more reliable. When I solve a problem or discover a useful trick, I write it down so I don’t lose the detail later.

This blog is also a bridge between my personal notebook and the wider internet. If someone else searches for the same issue, they may find these notes and save time.

What should be here

The posts here should be simple and useful:

  • notes from embedded software and electronics engineering work
  • lessons from bare-metal, microcontroller, and embedded Linux development
  • notes about server setup and container configuration
  • lessons from troubleshooting mail, web, or auth systems
  • debugging stories from firmware, communication buses, and desktop tooling
  • short explanations of why I chose one architecture over another
  • practical commands, file paths, and configuration tips
  • the type of memory I wish I had when I started the next task

A note for readers

If you are reading this, thanks for being here. This is my memory and my notebook, but you are welcome to use it too.

If you need help, feel free to ask. I can support you with ideas, troubleshooting, or by explaining the tools I use.


This is the first post in a simple tech diary. Future entries will be about the problems I solve, the tools I choose, and the ways I keep my infrastructure working.