My fascination with computers started when I was 12 years old. What began as curiosity quickly became a lifelong habit: whenever I encounter a technology that interests me, I want to understand how it works — and eventually build something with it.
My first computer was a TI-99/4A, with 16 KB of RAM, a 16-bit processor and a built-in BASIC interpreter.
By today's standards, 16 KB sounds almost comical, but to me it was an entire universe.
I started programming in BASIC and discovered something that would stay with me for the rest of my life: computers weren't just machines you could use — they were machines you could tell what to do.
That changed everything.
A few years later, in 1987, I bought my first IBM-compatible PC: an 8088 running at 8 MHz with 640 KB of RAM and DOS.
During my teenage years I also worked part-time at a local computer store, where I gained hands-on experience installing, configuring, repairing and troubleshooting PCs.
This was the era when understanding computers often meant understanding exactly what was happening underneath — memory, interrupts, hardware configuration, device drivers and the operating system itself.
When Windows first appeared, I wasn't particularly impressed.
Then I discovered Visual Basic 3.0.
Suddenly Windows programming became accessible and productive. I could create graphical applications quickly, experiment with ideas and see immediate results.
It dramatically accelerated my development as a programmer and made me want to understand more.
Naturally, that meant eventually confronting something considerably less friendly...
I decided to teach myself C++.
There were no online courses, Stack Overflow, YouTube tutorials or AI assistants waiting to explain why my pointer had just destroyed half my program.
I bought books, a copy of Borland Turbo C++ 3.0 for MS-DOS,
and started experimenting.
It was a difficult learning curve, but eventually C and C++ became the foundation for much of my professional career.
Learning them also established a pattern that has followed me ever since: when I encounter something complicated that interests me, I tend to keep digging until it stops being mysterious.
The arrival of Windows 95 opened another world.
I returned to C++ Windows development, this time using Microsoft Visual C++, and taught myself MFC and the Win32 API.
Gradually I moved deeper into Windows internals and system-level programming — processes, threads, synchronization, memory, IPC and the APIs underneath graphical applications.
Instead of merely using the operating system, I wanted to understand how software actually interacted with it.
Computer graphics had always fascinated me.
I experimented with rendering tools such as POV-Ray and studied graphics, image formats, color models and eventually 3D rendering.
Then I discovered DirectX and Direct3D.
That combination of mathematics, programming and visual results was irresistible. Graphics programming became one of my major technical interests and eventually led directly into my professional career.
I joined a startup developing 3D authoring technology, where I worked on graphics and animation systems.
Professional Windows development introduced me to another wonderfully complicated world: COM, ATL, MFC and low-level Windows architecture.
I worked on component-based systems, interfaces, graphics infrastructure and user-interface technology using C++.
Over time, debugging complex systems became as interesting to me as building them. Understanding why something behaved the way it did was often more satisfying than simply making the bug disappear.
Then came the Web.
I started learning HTML, Java, CGI, SQL and Perl, and took my first professional steps into software development at a web development company.
Because I already had a strong C++ background, learning new languages became increasingly easy. More importantly, I began to understand that programming languages themselves were only tools — what mattered was understanding the system and choosing the appropriate tool for the problem.
That idea would become increasingly important later in my career.
My work eventually expanded beyond desktop computers into embedded systems and Windows CE devices.
And that's when an interesting gap in my knowledge became increasingly difficult to ignore.
I knew how to write software.
I knew operating systems, graphics, APIs and low-level programming.
But what was actually happening underneath the software?
What exactly was the processor connected to? How did digital electronics work? How did software ultimately make something happen in the physical world?
I decided I wanted to find out.
So I started teaching myself electronics.
Once again, I chose the familiar route: books, electronics magazines, schematics, experimentation and a lot of trial and error.
This time, however, mistakes could occasionally involve smoke.
Unlike software, electronics doesn't always have an Undo button.
I concentrated primarily on safe, low-voltage digital electronics and gradually learned to read schematics, understand components and design and build circuits myself.
And then I discovered the device that connected this new world perfectly with the world I already knew.
Connecting the Software with Hardware - Microcontrollers.
Here was a complete little computer inside a chip — one that I could program, but which was directly connected to the physical circuit around it.
I started working with Microchip PIC microcontrollers, programming them in Assembly and C.
I deliberately avoided simply assembling ready-made kits. I wanted to understand the whole system: selecting components, designing the circuit, programming the microcontroller, defining communication protocols and writing the PC software that communicated with it.
For the first time, I could design both sides of the boundary between software and hardware.
One of my first ideas was deceptively simple: build a digital clock that wouldn't calculate time by itself, but would instead receive the current time from a PC.
Turning that idea into a working device required much more than displaying a few numbers.
I had to design the electronics, choose and program the microcontroller, drive the display, create a communication protocol, write the PC-side software, build the physical circuit and debug the complete system.
And it worked. You can see that all here.
Today's computers bear almost no resemblance to that TI-99/4A with its 16 KB of RAM.
The way I approach technology, however, hasn't changed very much.
I'm still curious about what's happening underneath.
I still enjoy encountering something I don't understand and figuring it out.
I still enjoy moving between layers — from hardware to operating systems, from graphics to distributed systems, and from microcontrollers to AI.
And after all these years, the part I enjoy most is still remarkably simple: