The Architect Who Never Was, Part One

How an engineering path shaped the way I design — and why it changed what I consider possible to build.

Design
Engineering
Frontend
Career
Learning
42 views

In the physical world, I always wanted to become an architect, but I became an engineer. In the digital world, the opposite happened: I started as an engineer and gradually moved toward architecture — only this time, the architecture of products, interfaces, and systems.

It took years to realize that I wasn’t just learning technologies — I was learning how to think about building things that other people depend on.

First steps: when a browser is enough

More than ten years ago, I wrote my first lines of HTML in a plain text editor. I didn't use any frameworks, build tools, or templates – just a file saved as index.html and a browser refresh button.

I remember the moment a paragraph I wrote appeared on the screen exactly where I expected it. It sounds trivial now, but at the time, it felt like direct control over reality. Type something, refresh, and see the result. No compiler errors or hidden processes. Just cause and effect.

Most of what I learned came from books, documentation, and trial and error. I would try something, break it, search for explanations, then try again. Progress was uneven but tangible.

Confidence grew quickly and faster than actual understanding. For a while, I believed I had figured out how the web worked. In hindsight, I had only discovered the surface.

The first real wall

JavaScript was supposed to be the next logical step. Instead, it became the first serious obstacle.

I started with a highly respected, very comprehensive book. Within a few chapters, I was lost. The explanations were precise, the examples were dense, and nothing connected to my mental model. Each page felt like proof that I wasn’t smart enough for this.

This wasn’t the first time I had encountered material written for experts rather than learners. During my engineering studies, some textbooks felt less like guidance and more like documentation for people who already knew the subject.

Eventually, I stopped blaming myself and started looking for a different entry point with simpler explanations, visual examples, and smaller steps. The concepts didn’t change, but the framing did. And suddenly things began to click.

The problem wasn’t my ability. It was that I had started with material written for someone much further along the path.

From tools to a system

For a long time, HTML, CSS, and JavaScript felt like separate disciplines. I learned, applied, and debugged them individually.

Then one day, while fixing a layout that behaved differently across browsers, something shifted. Changing the HTML structure affected the CSS. Adjusting the CSS exposed assumptions in the JavaScript. Fixing the script revealed weaknesses in the markup. It stopped being three problems and became one system.

From that point on, I couldn’t see them in isolation anymore. Every visual decision implied structural consequences; every interaction required coordination across layers. Instead of asking “How do I write this code?”, I started asking “How do these parts work together?”

SVG reinforced this perspective. On one project, I needed an icon that changed color, size, and subtle details depending on state. Instead of exporting multiple images, I embedded a single SVG and controlled it with CSS. One element replaced a collection of assets and became part of the interface logic. Visual elements were no longer decorations; they were programmable components of the system.

Crossing into the real world

Eventually, experimenting in isolation stopped being enough. I wanted to know whether what I had learned would survive real constraints like deadlines, legacy code, and other people’s decisions.

I delayed applying for jobs longer than I should have. When I finally did, the process moved unexpectedly fast: one test assignment, several long evenings, many revisions — and suddenly I was a Front-End developer working on a real product with real users.

The difference was immediate. While personal projects allow perfection, production work demands trade-offs. Code had to be readable, maintainable, and compatible with systems I didn’t design. Decisions had consequences beyond aesthetics.

That environment forced a different kind of thinking — less about what looks ideal, more about what works reliably.

Design that works — and design that doesn't

Working with designers introduced a new contrast.

Some layouts translated into code almost effortlessly. Spacing behaved predictably, components had clear states, and responsive rules made sense. Building them felt like continuing someone else’s reasoning.

Others looked impressive but collapsed under implementation.

I remember one project where a single page used multiple unrelated fonts, each introduced for visual variety rather than function. On another, I received a UI kit with button states labeled default, hover, and focus. However, when I opened the file, all three looked identical. I spent a while digging through Photoshop layers looking for hidden styles before finally asking the designer. Turns out there were none. She didn’t know what a hover state meant.

Moments like that revealed a gap between visual composition and product design. One produces images. The other produces systems.

That realization shifted my curiosity. I became less interested in how to implement interfaces and more interested in how they should be conceived in the first place.

The engineer's eye

My engineering background began to influence how I evaluated design decisions. Instead of focusing only on visual quality, I found myself thinking about durability: whether the solution would scale, how it would behave in edge cases, and whether another team could extend it later without breaking everything.

Interfaces started to resemble constructions — structures that must carry load, adapt to changing conditions, and remain understandable over time.

Without noticing it, I had moved from building screens to thinking about architecture.

Looking back

At the time, none of these steps felt like a transition into design. They felt like incremental adjustments to solve immediate problems more effectively.

Only later it become clear to me that understanding how things are built doesn’t just improve implementation — it fundamentally changes how you approach creation itself.

What began as learning to write code gradually became learning to design systems.

And that shift turned out to matter far beyond my first projects

What comes next — Part Two

IIn the next part, I’ll explore what happens when a developer decides to learn design — while still writing code every day. Also, we'll review how an engineering background shapes the way you read design theory, where it saves time, and where it quietly gets in the way.

It's not a story about whether designers should code; it's astory about what changes when they already know how.

Resources that shaped my path

These books and materials influenced me at different stages. Not all of them are beginner-friendly, but each became useful at the right moment.

Choose resources based on your current level, not their reputation.
The right material at the right time can change the trajectory of your learning.