I was eleven when a perfectly ordinary Microsoft Word file became something much more dangerous: an idea. I was using a vintage tube iMac, I changed the file extension, opened the result in a browser and watched a document behave like a tiny piece of the web. It was not a proper website by any serious definition. It was clumsy, limited and probably offensive to several standards that I did not yet know existed. None of that mattered. For a few minutes, I had discovered a secret door.
I learned the feeling before I learned the vocabulary
I did not begin with a course called “Introduction to Web Development.” I began with curiosity. That distinction still matters to me. Before I knew what semantic HTML was, I already understood the excitement of making something and seeing it respond. Before I understood the difference between design and development, I was already moving between the two without permission.
That first experiment did not teach me professional code. What it taught me was cause and effect. Change something in a file, refresh the browser, observe what happens. Break it, go back, try again. The web gave immediate feedback, and immediate feedback is addictive when you are a curious kid.
The wrong tool can still ask the right question
Today I would not recommend Microsoft Word as a front-end framework. I feel confident taking that controversial position. But I also would not erase that beginning from my story just because the tool was wrong. The important part was the question it created: if this can appear in a browser, what else can I make appear there?
That question led me toward interfaces, graphic design, code, photography, advertising and eventually the strange multidisciplinary space I work in today. The sequence was not neat. There was no master plan pinned above my desk. I kept following problems that interested me and learning whatever language the next problem required.
Building became my way of studying
Even after web design became professional work, I kept the habit of learning through construction. I like documentation and I respect theory, but I understand an idea more deeply when it has to survive contact with a real browser, a real viewport and real content.
A static design can hide many uncomfortable truths. The headline can always fit in the mock-up. The API is never slow in the mock-up. Nobody rotates the mock-up from portrait to landscape. Nobody has a weak connection, a long username, an old phone or an unexpected click. The moment a design becomes a working interface, it begins asking better questions.
That is why I still prototype early. I want to discover where the concept is fragile while changes are cheap. I would rather find an awkward interaction in a rough version than after I have spent hours making the wrong screen beautiful.
It also shaped the way I see design and code
I have never been very comfortable treating design and development as completely separate planets. They require different skills, but the visitor experiences one thing. A beautiful page that loads badly is not a beautiful experience. A technically perfect interface with no hierarchy or personality is not a complete experience either.
My first crude browser experiment accidentally taught me that visual decisions and technical decisions eventually meet in the same place: on somebody else's screen.
That idea has stayed with me through HTML, CSS, JavaScript, PHP-supported projects, responsive layouts, APIs and all the modern layers that arrived long after that first Word file. The technology changed. The basic pleasure did not.
I still want the small moment of surprise
There is a danger in becoming experienced: you can become efficient enough to stop being surprised. You know the patterns, the safe solutions and the reasons something will probably fail. Experience is useful, but I do not want it to turn curiosity into administration.
When I rebuild an old interface, connect a social API, design a small game mechanic or test an unusual navigation idea, I am still looking for a version of that first moment on the iMac—the moment when the browser does something I imagined and I think, “Oh. So this is possible.”
The tools are better now. My standards are certainly higher. The files are no longer pretending to be websites by changing their extensions. But the operating principle remains surprisingly similar: make something, look closely, learn from what actually happened, then make the next version better.
That is how the web entered my life. Not through a perfect first project, but through a mistake interesting enough to continue.
What I would tell the eleven-year-old version of me
I would not tell him to stop using the wrong tool. I would probably tell him to save more copies before changing file extensions, but the curiosity itself was doing exactly what it needed to do. The important habit was not technical correctness; it was the willingness to test an idea without waiting for permission or perfect knowledge. That habit still protects me from becoming too dependent on familiar workflows or from believing that expertise means staying inside a narrow lane.
When a project requires something I have not done before, I still return to a version of the same method: reduce the problem, make the smallest useful experiment, observe what actually happens and then learn the vocabulary required to improve it. The professional version is more disciplined and far less likely to destroy the original file, but the engine is recognisably the same. Curiosity creates the question; craft improves the answer.
That is why the first story still belongs in my portfolio. It is not impressive because a child discovered a secret trick in Word. It matters because it explains why I still treat technology as a material I can explore rather than a specialist territory I need permission to enter. The tools became more sophisticated. The useful instinct was already there: make something real enough that reality can teach you back.