The Joy of Building

Anyone who knows me knows that I have a passion for LEGO and might assume that the title refers to it. But the real subject of this article is what has always fueled my career as an engineer: the joy of building.

I am writing this because the transformation currently reshaping software engineering often calls into question the tools of the trade, the way we work, and even whether our profession is still necessary. All of this creates anxiety and unease among many colleagues, driven by uncertainty and change. An entire narrative feeds on these emotions, and I would like to help challenge it.

Before managing teams of engineers, I was a full-time software engineer for more than ten years. What I want to talk about, however, has much deeper roots. It goes back to middle school, when I first approached computer science by following the example of my older brother.

The first PC I remember having at home was a Pentium II housed in one of those yellowish metal cases, running Windows 98, with a CD-ROM drive, a floppy disk drive, and, soon afterward, a 56K modem. Whenever we tried to browse the internet, I would regularly hear my mother’s voice through it because she had picked up the phone.

I used that PC to play a long list of retro games that I could name just to trigger your nostalgia, but that would be cheating, so I will focus instead on the first program I worked on.

I think I was 12 when I tried to build fantasy football management software using Microsoft Access and VB6. I had never taken a computer science course, so my only teacher was my brother, who was six years older than me. I remember very little about that software, apart from a few things: the terrifying user experience of Microsoft Access and its record navigation, the fact that I never actually used the software, and, most importantly, the powerful and intriguing feeling that I could create anything without having to depend on anyone else.

During those early years, I created many other software applications, none of which survived for very long. I built a couple of them on commission for small amounts of money. I made one in exchange for piano lessons, which I soon abandoned after realizing that the piano was not for me. I still delivered the software, though!

Why am I telling you all this? Because I tried to understand what drove me most strongly toward this profession, and I realized that it was precisely that feeling of being able to create anything, and the satisfaction that comes from doing it.

When talking to colleagues from different companies, I have often heard some version of this: “When you work on a product, the reward you get from your work is much greater. You see someone using what you created, and you know that you solved a problem for them.”

I partly agree. When that happens, it is certainly gratifying. But on reflection, at least in my experience, the greatest satisfaction does not come from the problem being solved, but from the act of creation itself. And I cannot deny that there is also a certain degree of narcissism that drives us to seek the most elegant and perfect solution, one that we can look at with pride.

The best analogy I can think of is the story of Dr. Frankenstein. The doctor’s moment of greatest joy, after all his efforts, comes when he finally sees his Creature come to life and exclaims, “It… can… be… done!”

He is not celebrating because he has brought a human being back to life or solved seemingly impossible medical problems. His joy comes from the satisfaction of having succeeded, of having created something unique through his own efforts. In my imagination, Dr. Frankenstein felt the same thrill I did when I built my first piece of software at the age of 12.

Someone once told me, “Perhaps you are a maker, a product person more than an engineer.”

At first, the comment annoyed me because engineering has always felt like an essential part of who I am. Later, however, I realized how shortsighted that distinction was. Treating these two aspects of software creation as separate is a serious mistake.

Today, AI is reducing the weight of the execution phase, and we are starting to talk about Product Engineers more naturally. But people capable of designing software with a product mindset have always existed, and you will find them in almost every successful product team.

Personally, I find the idea of designing software without knowing or helping to shape its functionality deeply frustrating. Helping to shape it, of course, does not mean deciding everything alone. We cannot presume to be equally knowledgeable about technology and a particular domain unless that domain is extremely simple. But if we do not begin with the problem, we are very likely to build a beautiful solution to a problem that does not exist.

Today, I encourage the engineers on my teams to start from problems, not tasks: to understand the problem, take responsibility for it from beginning to end, and translate it into a solution, whether technological or otherwise. This creates ownership, helps us avoid solutions that exist only for their own sake, and allows people to grow beyond their technical abilities.

Given this view of software engineering, isn’t AI an accelerator rather than a replacement?

If we move beyond the idea of the factory or the assembly line, we discover that mere execution, the act of writing code, is not the part that creates the most value. It was our limiting factor.

Writing a program and seeing it work could be rewarding, just as refactoring a system to produce the same result with a fraction of the code could be. But how many times have we felt frustrated because an idea that was already perfectly clear in our minds still required days of fitting characters and words together, debugging, and writing tests?

Since becoming a manager, although I have always remained hands-on to some extent, a lack of time had taken away my habit of experiencing that satisfaction that comes from creating. At most, I could build a small prototype.

Whether for a personal or professional project, AI now allows me to experience that feeling again. Not only that, but I have also found myself revisiting old ideas that I had abandoned because I lacked the time or energy to pursue them. All of this has come with a healthy dose of learning: new technologies, new tools, and new techniques.

I am having as much fun as ever, perhaps even more.

I realize that my experience is deeply personal and may not be the norm. I understand and acknowledge all the nuances and contexts in which many of these ideas do not apply. Still, I wish this interpretation of the current transformation were more widespread and could help other engineers benefit from this technology without passively submitting to it.

By now, the conversation is overflowing with discussions about replacing developers and about the evolution of our roles and our industry. Many of these predictions will probably prove false, while some will turn out to be true. But my advice is not to pay too much attention to sensationalistic predictions about our profession.

Instead, think of something you would like to create. Something useful to you or to someone else. One of those ideas that once made you think, “If only I had the time, I would build it myself, exactly the way I want it.”

Then get to work.

Use a coding assistant, discuss the specifications methodically, build the product, try it, and change it. Keep going until you stop, look at it, and think, “Well, look at this beautiful little thing I’ve created.”

I am convinced that you will rediscover the joy of building.