Short biography

Programming has been a passion of mine for as long as I can remember. It began as a childhood hobby, gradually became a serious interest, and eventually became my profession. Even after all these years, however, it has never stopped being a hobby as well.

How it all started

It all began while I was still in elementary school, when I asked for an IBM-compatible PC for Christmas. My family tried to convince me to choose a C64 or C128, an Amiga, or another computer that was cheaper, more suitable for children, and better for games and multimedia.

I was not particularly interested in playing games, though. Several of my friends already owned C64s, so I was somewhat familiar with them. Another friend had a PC at home. It was less appealing as a games machine, but I was fascinated by its possibilities. It offered no colorful graphics or synthesizer-like sound. It was mostly limited to text mode and black-and-white Hercules graphics, but it had a lot of RAM and, for its time, a powerful CPU.

My first computer was an 8 MHz 8088 XT with 1 MB of RAM, EGA graphics, a monochrome amber monitor, two 5.25-inch floppy drives, and no hard drive. The graphics hardware supported 16 colors, but on my monitor they appeared as 16 different levels of amber brightness.

I later received a C64 from relatives, but for me it remained mostly a gaming machine. The PC was where I learned to program. I started with GW-BASIC and x86 assembly, followed by several other BASIC dialects and clones. Some of my earliest assembly experiments involved low-level keyboard handling and system interrupts. One of them was a keyboard logger, which was certainly a questionable teenage project, but it taught me a great deal about how closely software could interact with the machine.

Soon after leaving elementary school, I discovered Turbo Pascal. It allowed me to move beyond small experiments and write my first useful applications, although I never released any of them. A friend and I once wrote a mathematics learning application in a compiled BASIC dialect. I also wrote a small game in Pascal, but had to abandon it because I was not very good at drawing sprite graphics.

From DOS to the desktop

I continued using the 8088 for a remarkably long time. My family simply could not afford a 286 or 386, so I eventually upgraded directly from the XT to a 486.

The 486 also brought Windows into my life, but I initially had little use for Windows 3.1 as a programming platform and continued to work mainly in DOS. I still wrote small programs in QBasic that could have been compiled into standalone executables using QuickBasic, which I unfortunately never owned.

Then came Windows 95 and Delphi, and I finally left DOS behind. Delphi's object-oriented Pascal environment gave me practical access to graphical application development and made it possible to build the kinds of GUI applications that had previously seemed out of reach. I created various Delphi tools for friends and family.

Around the same time, Java appeared with a major promise: platform-independent software. That idea fascinated me, so I learned Java before I had properly learned C and at a time when C++ was little more than a name to me. Java stayed with me for many years. I once reimplemented bzip2 in Java, mostly because I wanted to understand how it worked. When I began using Linux alongside Windows, however, C became unavoidable.

The slow road to the Internet

I gained Internet access relatively late at home, at least compared with much of the rest of the world. During the DOS era, I already used a 14K modem to access mailboxes, message classmates, and download software. Those who know, know. Only with Windows 95 did I finally gain access to the Internet itself, first through a 28K and later a 56K modem.

There were no flat-rate plans available to me at the time. Internet access was charged by the minute, which made efficiency and data usage very real concerns. Downloads had to be planned carefully, unnecessary traffic cost money, and large files required a great deal of patience.

It took a long time before I finally received a 128 Kbit/s ADSL connection. Even today, my Internet connection is comparatively slow. I am still far from gigabit speeds and do not even have a 100 Mbit/s line.

Growing up with limited bandwidth, limited storage, and limited computing resources probably contributed to my preference for efficient software. Resources should be used deliberately rather than treated as unlimited.

Learning English the unconventional way

For the first half of my school years, I was only an average English student. Over time, however, my English improved considerably, and by the time I graduated from high school, I was one of the top students in my class.

That improvement began even before I had Internet access. English-language computer games were an important influence. I especially enjoyed adventure games by Sierra and LucasArts, where understanding dialogue, descriptions, and instructions was often essential to making any progress. Role-playing games also contributed a great deal to my vocabulary and reading comprehension.

Later, I read a great deal of technical documentation in English, since much of the really useful material about computers and programming was only available in English. This gave me a strong technical vocabulary and made me comfortable reading complex English texts.

When I eventually gained access to the Internet, an entirely new world opened up to me. I was an anime fan, but there was very little local anime fan community where I lived, so I looked for communities online instead. English was usually the common language, which gave me a reason to use it actively rather than merely read it. I sometimes spent hours a day in anime-related Usenet groups. Ah, Usenet. Those were the days.

At the time, dubbed versions of many anime series were difficult or impossible to obtain, while Japanese releases with English subtitles were often much easier to find. I therefore also spent a great deal of time reading English subtitles.

Games first strengthened my general vocabulary and reading comprehension. Technical documentation later gave me a solid command of technical English, while anime and international fan communities added the everyday, informal, and conversational language that school lessons rarely taught.

The web, Unix, and a detour through university

As the World Wide Web grew into a major platform, I taught myself HTML, later followed by CSS. JavaScript followed over time, and regular expressions became one of my particular interests.

I later began studying computer science in a traditional German Diplom program. While attending university, I also became certified as a Java developer. I subsequently started vocational training as an IT specialist in software development and eventually left university without completing the Diploma.

By then, I had completed roughly the amount of study that would later have been associated with a bachelor's degree. However, bachelor's and master's degrees had not yet been introduced into the program, so there was no bachelor's degree I could have earned or formally completed. During that period, I also learned PHP, Perl, and SQL.

At the same time, I used Windows less and less. Eventually, I left it almost entirely behind and discovered that it was perfectly possible to live and work without it. At university, I worked extensively with Unix systems such as AIX, IRIX, and Solaris, as well as Linux.

I only became interested in Macs with Mac OS X 10.2. I had never liked the classic Mac OS and found it rather unpleasant to use. Mac OS X was different. Its Unix foundation and roots in NeXT made it a much more compelling system to me. NeXT had always seemed far more interesting from a technical perspective than the classic Macintosh platform.

Today, I primarily use Macs as my desktop and development systems. I use Linux for servers, embedded devices, test systems, and as the basis for systems I build, but not as my primary desktop environment.

When the hobby became the job

Once I began working as a professional software developer, new technologies followed in rapid succession. I worked with Ruby and Objective-C, later with Swift and TypeScript, and with various other languages depending on the needs of individual projects.

Some projects even involved bare-metal programming. I have worked with ARM assembly, and I have written OpenGL shaders for a commercial project.

I do not currently have practical experience with C++, Python, or Rust. I may be able to follow parts of the code and get a general sense of what it is doing, but I would not claim proficiency in any of these languages. That said, I am a quick learner and regularly teach myself new programming languages and technologies.

If it does not exist, build it

One of my main motivations is dissatisfaction with existing solutions. Software rarely convinces me in terms of quality. Too often, developers appear to ignore what users actually ask for while implementing features that few people need and nobody requested (yes, I'm looking at you, Mozilla; I'm still using Firefox, though). At the same time, basic usability, reliability, efficiency, and long-term maintainability are often totally neglected.

When existing software does not solve a problem properly, my natural response is often to consider building a better solution myself. That does not mean every idea becomes a finished or successful project. Most do not. For me, however, designing and implementing an alternative is often the most direct way to understand the problem and explore how it could be solved differently.

It is also simply fun. Even when an idea leads nowhere, I have still been doing it for my own entertainment.

Simple, but not simplistic

I prefer code that is simple and efficient, but simple does not mean simplistic. Software development often rewards solutions that are quick to adopt but considerably more complex than the original problem requires. These solutions can overshoot the actual goal while still failing to remain extensible, maintainable, or suitable for future requirements.

I prefer to understand a problem thoroughly and build the smallest design that solves it well without closing off sensible paths for later development. I value software that is robust, understandable, and built to remain useful for a long time.

I appreciate polymorphism and abstract interfaces, but I am skeptical of traditional object-oriented programming, particularly inheritance. Inheritance can create rigid and fragile relationships between components and is often used where composition or explicit interfaces would be safer and easier to understand.

I strongly prefer statically typed languages. Type checking during the build process prevents entire classes of avoidable errors before the software is ever executed.

I also avoid unnecessary dependencies. A dependency may save some initial effort, but it introduces external complexity, compatibility risks, maintenance obligations, supply-chain concerns, and decisions outside my control. Dependencies are sometimes necessary, but their long-term cost should justify their value.

Closer to the machine

I feel more at home close to the system than in user interface work. My favorite development platforms are macOS and Linux, particularly for native applications, system software, network services, protocols, embedded systems, and tools that solve practical problems without unnecessary complexity.

When given a choice, I prefer low-level languages such as C. These languages have relatively few hidden runtime mechanisms. They give direct control over memory, data structures, and representation. They are highly portable, produce small binaries, require no large runtime environment, and can be extremely fast.

I also appreciate that they do relatively little behind my back. They may require more care from the programmer, but the relationship between the code and the resulting program is usually much clearer than in larger and more abstract environments.

I enjoy understanding systems from the lowest practical level upward. I would rather know what a component is doing than treat it as an unexplained black box.

AI is a tool, not the engineer

Today, I also use AI-assisted development, but I see AI as a tool rather than a replacement for engineering knowledge and programming skills. It is a tool, just like a compiler is a tool.

A non-developer using AI is somewhat like a person who owns the best agricultural machinery but knows very little about farming. The machinery may still be useful, but it does not determine the quality or quantity of the harvest. Knowledge, judgment, planning, and experience remain essential.

AI can accelerate development, help explore alternatives, and reduce repetitive work, such as writing documentation or unit tests. It cannot replace the ability to recognize whether a solution is correct, appropriate, maintainable, or secure. It cannot replace the need to design software architectures, interfaces, and APIs, and especially not the need to write and understand your own code.

When I am not programming

Outside software development, I am curious about a wide range of subjects. Science is a major interest of mine, particularly physics and astronomy, but I also enjoy unusual facts, obscure details, myth busting, and going down the occasional rabbit hole. I like watching people explore, explain, build, or restore things, though sometimes I am simply looking for something funny or entertaining to watch.

I have little interest in social media and am largely absent from social networks. YouTube is the main exception, as it is where I watch most of the content mentioned above. I generally don't watch television at all, I might watch 2–3 movies a year, and aside from Rick and Morty, I have never streamed any TV show. Occasionally, I do watch indie productions on YouTube.

I also enjoy cooking, even if I would not claim to be a particularly great chef. I like reading bedtime stories to and with my daughter, and I listen to a fairly mixed selection of music, including Asian pop, remixes and mashups of songs from the 1970s through the 1990s, and Electric Callboy.

What I build for myself

The projects I publish on Codeberg, GitHub, and other platforms are personal hobby projects. They are not related to my employer, my professional work, or any commercial activity. They reflect my own interests, experiments, and ideas, and I make them available in case others find them useful.

I generally prefer Codeberg for personal projects because it is an independent, community-oriented platform, but some projects may also be published on GitHub. Licenses vary by project, so please check the license information in each repository.

Contact

You can contact me at 19plw1f47@mozmail.com.

This is a heavily spam-filtered relay address and may be deleted at any time. Messages that appear too much like spam may not be delivered.