Thirty Years of Building Software
It probably started when I was very young.
My father worked in an industrial automation department that housed a Soviet counterpart of the IBM System/360-370. Sometimes he would lift me through a window into the computer room. I still remember the massive keyboard they let me play with. To a child, it felt like touching something mysterious and almost magical.
During my high school years, I spent most evenings in my father’s office. That was where I first encountered an EC-1840 personal computer. At first I simply played games, but before long I wanted to write programs myself. I still remember the feeling. You gain access to a computer and suddenly find yourself in a world where ordinary limitations disappear and almost anything seems possible. It felt like magic.

In ninth grade, a friend told me about a nationwide student conference organized by MIPT. By then I had written a graphics editor in BASIC, prepared extensive documentation, and submitted it for review. I was invited to Khimki. Looking back, I suspect the documentation impressed the organizers more than the code itself.
The trip left a strong impression on me. For a boy from the provincial city of Bobruisk, attending a conference near Moscow was a major event. My project was highly rated, and I received a scholarship from the Lenin Children’s Foundation.
I returned home energized and full of ideas. In tenth grade, I wrote a primitive line-by-line Russian-English bidirectional translator in Turbo Basic. After submitting it to another conference, I decided to go further and rewrote it in C++, complete with a Turbo Basic-style user interface. By the standards of the time, it looked quite impressive.
At the conference, the section chairman asked me to leave the new version with MIPT. That was my first encounter with what I later learned was called a “gentleman’s agreement.” I was promised payment, but never saw any money. Oddly enough, that did not discourage me. If anything, it made me even more interested in pursuing software development.
Before entering university, I became completely obsessed with programming. I constantly felt that I was on the verge of discovering something important. It seemed that if I just worked a little harder, I would come up with an idea capable of changing the world. Even during military training camps, when I was assigned night duty in the barracks, I would spend hours writing code fragments and algorithm sketches on scraps of paper while everyone else slept. The great breakthrough never came. What I did discover was what I wanted to do with my life.
At university, I met a friend and like-minded developer, Igor Kolupaev. At that time, the Internet barely existed in Belarus. Software and knowledge were exchanged through FidoNet and, more often, through personal connections.
One day we came up with the idea of collecting the best software projects created by students from universities in Minsk, packaging them as an electronic almanac, and distributing them on 3.5-inch floppy disks. Some of the software was genuinely impressive. One project was an alternative to Norton Commander that I personally used for many years afterward.
We completed the first release, but never managed to secure a distribution agreement. The project ultimately went nowhere. Still, it was my first experience with the value of openly sharing software and knowledge. In a way, I became involved in Open Source long before the term itself became widely known.
In 1998, I finally gained access to the Internet. After learning Perl, I began turning my ideas into personal web projects. The Belarusian Internet was still largely empty, so even relatively simple services could quickly attract an audience. One of my projects was a banner competition platform. Anyone could register and upload a banner design, while other users could vote and leave comments.
Around that time, an informal group was formed in Minsk by people involved in developing the Belarusian Internet. There were only about a dozen of us. I was genuinely surprised when I was invited to join. We met regularly, discussed new ideas, and debated where the Internet was heading and what the Belarusian online world might look like in a few years.
More broadly, it was an exciting time for the entire industry. The community was small but incredibly active. There were technology parties, conferences, national competitions, and countless experiments. As the Internet gradually became a visible part of public life, people from the industry were often invited to appear on television. I was among them and took part in a number of TV programs and discussions over the years. Today it may sound unusual, but back then almost everything felt new. Every project was an experiment. Many things were being done for the first time.
In 2000, I moved to Minsk for work. It was the era of web portals. At the time, portals seemed like the answer to everything. We tried building one ourselves without really understanding what problem it was supposed to solve. Unsurprisingly, the project went nowhere.
What did come out of that period was an idea for an electronic publishing platform. I brought the concept to Atlas, where I developed MySite CMS, before the term CMS had become widely used in Belarus.

A few years later, I joined Red Graphic and created Site Sapiens CMS. Looking back, I still believe Site Sapiens was ahead of most local competitors, especially in its tree-based content structure. At the time, however, I cared far more about adding new features than about architecture or maintainability.

Only later did I realize how important maintainability really is. Writing code that works is only half the challenge. Writing code that can still be maintained and extended years later is much harder. That realization eventually led me to study software architecture and engineering practices much more seriously.
Ironically, my long-standing fascination with CMS platforms eventually brought me to Crytek. The company was assembling a team for a new web project and believed my experience building content management systems would be useful.
When I moved to Frankfurt in 2009, PHP was still my primary language. I was skeptical of JavaScript. Prototype-based object-oriented programming felt strange and unfamiliar. At the time, JavaScript was mostly viewed as a browser scripting language.
But the web was changing rapidly. Client-side applications were becoming increasingly sophisticated. Node.js appeared and introduced the idea of server-side JavaScript. That was when I began taking the language seriously.
Over time, I realized I had once belonged to the exact category of developers described by Douglas Crockford in his article JavaScript: The World’s Most Misunderstood Programming Language. To be fair, JavaScript before ES6 had significant shortcomings. Libraries such as jQuery emerged for a reason. They helped developers work around many of the language’s rough edges.
What bothered me most was the lack of familiar object-oriented syntax. One of my earliest GitHub projects, xObject, was an attempt to make object-oriented programming feel more natural.
With the arrival of ES6, JavaScript changed dramatically. The language became more expressive and far more pleasant to work with. Even before that, it had already given us technologies such as WebSocket, Server-Sent Events, and WebRTC. Later came Service Workers, Push API, async/await, and many others.
Over time, JavaScript evolved from a browser scripting language into a universal platform. Developers began using it on servers, desktops, mobile devices, automation systems, and even in game development.
My introduction to frontend frameworks came relatively late. At Crytek, I was once assigned a small desktop application built with NW.js. I remember a colleague asking me: “Why do you keep writing everything in vanilla JavaScript instead of using a framework?”. At the time, I cared deeply about how much code an application had to load before it became usable. I had just finished jsic and was pleased that I had at least managed to organize my code into logical modules.
Still, the question was valid. As applications grew larger, maintaining them became increasingly difficult. Among the frameworks available at the time, I chose Backbone. It was lightweight, unobtrusive, and fit my way of thinking. That decision led to several experiments, including ng-backbone.
In the early 2010s, React arrived. Combined with server-side rendering, hydration, and ecosystems such as Express and Koa, it made PHP largely unnecessary for many of the projects I worked on.
Although I had spent decades working with PHP, I was never entirely comfortable with its inconsistencies. The language often felt as though it had evolved organically rather than according to a coherent design.
Even so, a hand-assembled React and Express stack always felt incomplete. Responsive image handling required separate solutions. LQIP implementations were largely DIY. Every project seemed to involve assembling the same collection of independent tools over and over again.
The first platform that felt truly complete to me was Next.js 15. For the first time, many problems I had spent years solving manually were built directly into the framework.
Looking back, I realize I entered the industry just as web development itself was becoming a profession. Today we are witnessing another major shift as more and more tasks are being delegated to AI systems.
Sometimes it feels as though I have lived through the entire lifecycle of the industry.
In the 1990s, I wrote assembly language routines to create pseudo-graphical interfaces and animated starfield backgrounds for Clarion applications. In the 2000s, we built dynamic drag-and-drop interfaces in JavaScript, a language many people still considered a toy. In the 2010s, I created a no-code test automation tool that could dynamically install NPM dependencies and execute Jest tests inside an Electron desktop application.
Every decade brought a different set of challenges. Every major technological shift forced developers to rethink old assumptions and learn things that had seemed impossible only a few years earlier.
We’ll see where all of this leads next.