Every technology professional has an origin story. Mine began in 1995, centered around a Packard Bell corner computer running Windows 95.
This beige chassis dominating the desk instantly transports me back to the very beginning of my career. I do not just see outdated hardware; I feel a profound nostalgia for the quiet, uninterrupted hours I spent discovering the inner workings of operating systems and programming languages.
That computer was my gateway into the digital realm.
First programming language
The idea of computers controlling vehicles and medical devices remotely with artificial intelligence, as depicted in the science-fiction movies I watched on VHS at the time, encouraged me to explore programming.
As a teenager in 1995, I began learning to code using Visual Basic 4. Despite its constraints, Visual Basic 4 was an essential first step because its drag-and-drop interface and event-driven model allowed me to immediately see the results of my logic.
My first major project was a digital pet similar to a Tamagotchi, the global phenomenon of 1996. The basic mechanics functioned well, but it taught me about time-delta calculations when I tied the pet’s hunger decay to the processor speed instead of real-time intervals. During this period, I consumed my first books on programming, deepening my understanding of software development.
A significant challenge that forced me to learn the command-line…
In a misguided attempt to clear a few megabytes of disk space, I noticed a file named io.sys.
Assuming anything with such a short, cryptic name could not be important, I deleted it.
After rebooting the computer, the operating system failed to initialize. The screen displayed the error: “Non-system disk or disk error.” This was a cold-sweat lesson in operating system architecture.
MS-DOS and writing my first video game
The “Non-system disk or disk error” error forced me, for weeks, to boot the computer using a MS-DOS rescue disk. Using DOS forced me to read a book where I learned the command-line, and I soon discovered Quick Basic 4.5, which renewed my enthusiasm.
My programming journey took a significant leap forward when I discovered Quick Basic 4.5. I remember typing in a sample piece of code that switched the display mode to SCREEN 13, unlocking a specific graphical resolution in 256 colors. As simple, brightly colored circles and squares materialized on the monitor, a single thought instantly crossed my mind: “It’s great. I can make video games with this.” That exact moment is where my journey into game development started. I began with modest projects, writing small tools like an XOR encryption program to hide text files, before moving on to interactive entertainment. My very first game was a simple space evasion title where the player had to maneuver a little airplane to avoid a barrage of falling asteroids.
As my ambition grew, I realized the standard graphics commands were a bit too slow for the smooth action I wanted to achieve. This led me to discover external assembly libraries like Future Software and DirectQB, which opened the door to making Quick Basic 4.5 games that were far more complicated. With these new capabilities, I designed a full platform game built on a scrolling engine. I managed multiple visual layers drawn one behind the other to create a sense of depth. I had one layer dedicated to the static background and another for the solid level tiles. The active foreground layer contained the main character, alongside monsters, boss encounters, coins and other collectibles.
Following my time with Quick Basic, I transitioned to developing games in C using the DJGPP compiler and the Allegro library. This shift moved me closer to the hardware and introduced me to more sophisticated programming paradigms. This experience with C was important in preparing me for the rigorous demands of enterprise-level software development and Linux infrastructure management.
I switched to GNU/Linux
A key moment in my technological journey occurred in 1999 when I began using GNU/Linux, a transition that served as the natural evolution of my time with MS-DOS. My forced immersion in the DOS command line after the io.sys incident had changed how I interacted with computers, shifting my preference away from graphical interfaces and toward the precision of text-based environments.
I had grown to enjoy the granular control and the intellectual rigor of overcoming technical challenges. GNU/Linux offered the ultimate playground for this mindset, providing a transparent architecture where I could apply my growing skills in C/C++ and shell scripting to solve complex infrastructure problems.
Installing Linux in the late nineties was not for the faint of heart; it often involved, for example, manually calculating monitor refresh rates for the XFree86 configuration. My journey included experimenting with several distributions: Caldera OpenLinux, Mandrake, Debian, SuSE, Fedora, RedHat, Gentoo, Ubuntu, and Arch Linux.
I collected installation CDs like trading cards. Each version provided distinct insights, and the Linux community proved to be an invaluable resource, filled with individuals keen to share their knowledge and rescue me from my frequent configuration errors. During those early Linux days, getting hardware to work was a notorious rite of passage.
This transition shifted my entire focus toward system administration, infrastructure, and operating system development. I studied computer networking in depth, specializing in the field, which inevitably led to some memorable learning experiences. To make the machine serve my exact needs as a software developer and administrator, I wrote hundreds of C, C++, Python, Perl, PHP, Bash shell scripts, etc.
Alongside my Linux system administration and software development adventures, I fell down the rabbit hole of text editor customization. I initially used Vim, spending hours tweaking its configuration and writing my own extensions until it functioned as a complete IDE.
However, the true turning point was my eventual switch to Emacs, which stands as my favorite editor today. The learning curve was steep, especially when diving into Elisp to customize my setup. There were definitely weekends where I spent more hours tweaking my configuration file to make the syntax highlighting look absolutely perfect than I spent writing actual software. The transition from Vim to Emacs required a massive effort, as I spent countless hours diving into Elisp, another of my favorite programming languages, to reimplement in Elisp the Vim plugins and scripts I had previously developed. Learning Elisp allowed me to fully bend the editor to my will. There are many specific reasons why I ultimately left Vim behind to make Emacs my permanent digital home, but I will detail those arguments in a future article.
Professional
Following this, I spent over two decades as a software development and Linux infrastructure professional across multiple corporations. I might never have pursued this career path had it not been for the incident where I deleted io.sys! As I moved into enterprise environments, the foundational lessons learned from recovering a broken boot sequence evolved into architecting resilient Linux servers and developing software.
Conclusion
Reflecting on my shift from DOS and Windows 95, I realize the significant impact that hands-on problem-solving and continuous learning have had on my career. The technology landscape has transformed considerably over the years, yet the excitement of discovery remains the same. This journey has been about more than personal growth and technical skills; it is also about the connections I have made and the supportive community around me. My experience highlights the dynamic nature of technology, where deleting a system file is a learning opportunity, and every new interest can lead to significant discoveries.