It begins with you being a user. You enjoy the experience, learn the rules, play and relax. Then, sometimes, it continues with curiosity—to see behind the curtains, eager to modify those rules or create new ones.

Transitioning from your first computer language to own the mindset of an engineer can be difficult, frustrating, and often a tediously long procedure. You can always find shortcuts, practice through days and nights, but even with the toughest, most nonsensical parts, you cannot predict when things will click. But eventually, they will.

My journey began with a national program that brought free broadband connectivity to high schools in Hungary. I was so much mesmerised by the information highway that on some days, I just couldn't go home after my classes. I spent afternoons in a lonely basement where we ran the school's web server on an i486, building websites or simply chatting with unknown people from around the world. In 1998, I stepped into the era of Netscape Navigator, Hotmail, and various Telnet applications. I started with HTML, and later, someone showed me how to capture and process POST requests using Perl.

A couple of years later, PHP 4 arrived into my life, followed by Postgres, MySQL, and my first CMS / framework called Typo3. However, programming was still just a hobby for me. I found more confidence in designing websites. A decade later, in 2008, I learned a golden rule: you can't be perfect in everything.

This is one of the things that companies often misinterpret: the term "full stack". It doesn't mean you have to be equally great in frontend, backend, and devops; it means you have the right skills to navigate through the common obstacles of web development. It means having the ability to build and ship a product or application from scratch, even if the end result isn't necessarily perfect. Perfection is a programmer's holy grail, something we often strive for it, but can never reach it. Simply because it doesn't exist. There's no perfect code—only code that is safe to be shipped because it gets the job done. The evolution of software is a natural part of the process and is equally important as the personal growth of the person who writes it. More knowledge and experience make you think smarter and faster, reducing the amount of fear of the unknown.

Returning to my story, I realised the need to specialise. I accepted that I couldn't be equally great in all areas, but I enjoyed writing HTML and CSS, you know making Photoshop layouts alive, so maybe I could call myself a site builder.

From 2013, my unique skill set was PHP, although I learned it the hard way: fake it until you make it. But it made me fall in love with backend programming and introduced me to concepts like dependency injection and the repository pattern. With CodeIgniter, Laravel and Yii, I arrived in a perfect time to be witness of the language's resurrection. After introducing the PSRs, the history of modern PHP evolved rapidly; they even skipped PHP 6. Later, I was pushed to learn new things about frontend (jQuery, ES6, React, Vue), with detours in mobile and desktop application development, then SaaS, microservices, CI/CD pipelines, serverless architecture, infrastructure as code, design patterns, SOLID, DRY, YAGNI, TDD, and BDD—so many things that my brain needed more time understand. Some started making sense within a month, while others took a year more to click. Today I'm no longer addicted to Laravel, and I seize every opportunity to try out languages other than PHP.

What I'm trying to tell you through my story is that you must always remain open and hungry. Don't stick to one framework or one language. Learn the basics, variables, loops, control structures, and data structures. Learn from the mistakes or journeys others have made: design patterns, software paradigms—programming is a flat circle, everything else are just SDKs and APIs to memorise. Read about algorithms, how to be more effective or improve performance. There's nothing new under the sun, just better tools which are naturally faster, perhaps a bit shinier, but the foundations are always remain the same. Some are better suited for the task, while others are less. Invest enough time in learning everything about your task, inspect any inherited code, then make the best decision about tools, architecture and approach based on all the information you have.

Prioritise simplicity over complexity, focus on input and output, try, fail, and then try again. Once you've learned these things, you're no longer just a full stack, ninja or 10x developer. You're a software engineer armed with the right tools and mindset to do the best you can: write software.