I’m a self-taught developer.
Today I’m publishing this article because my daughter just turned eight. Her birthday always reminds me of a very specific period in my life. When she was about to be born, I was still wondering whether I would actually manage to land a job and provide for her.
Learning to code alone is exciting, but it also comes with a lot of doubt. Tutorials make things look simple, but the real question is always the same: will someone trust me enough to hire me?
Back then, I didn’t know the answer yet.
January 2018: The First Opportunity
In January 2018, the company Manao hired me as a full-stack PHP developer.
I was extremely grateful for that opportunity. Hiring a self-taught developer who has never worked in a professional environment requires a certain level of trust. They gave me that trust when I needed it the most.
At that moment, it wasn’t just a job. It was proof that the hundreds of hours spent learning alone were not wasted.
The First Week
The first week was brutal.
Suddenly I was facing a real production codebase written by experienced developers. I could read the code, but understanding the structure, the conventions, and the logic behind everything was another story.
Every evening after work I opened my small Celeron laptop (which I still own today, still running Kubuntu). That poor machine survived countless late nights of debugging, tutorials, and experiments.
And every night I restarted from the basics.
HTML. CSS. JavaScript. jQuery. PHP.
I relearned everything I thought I knew.
One funny thing about that laptop: if I opened too many browser tabs while running a local server, the fan would start screaming like it was about to take off. It forced me to stay disciplined with my workflow.
But after a week of intense catching up, things started to make sense again.
The First Three Months
After that first week, everything became smoother.
I started understanding the project structure, the workflow, and the habits of the team. Slowly I went from trying to survive the codebase to actually mastering parts of it.
The project I was working on was an internal accounting SaaS application. Before that, I had never touched anything related to accounting systems. Suddenly I was dealing with invoices, financial logic, and business rules.
It was a completely new world.
During that time, the director also taught me several small professional lessons that stayed with me for years.
One day I came to work wearing a sleeveless shirt. Instead of making a scene, he simply told me calmly:
“Go put your pullover back on.”
Message received.
He also taught me practical habits about software quality. For example:
- When testing something, avoid writing meaningless placeholders like
test123. - Use realistic data so the test environment reflects real situations.
- Keep the code readable. A well-aerated file is easier to maintain than a compressed wall of text.
Those things might sound small, but they shape how you approach your work.
Those first three months were my probation period, and honestly they taught me more than most tutorials ever could.
Growing Responsibility
As time passed, I started receiving more responsibilities.
Complex tasks started landing on my desk regularly. For some reason, I became the person who got assigned the more challenging problems.
One moment that stayed in my memory involved a massive Excel file.
The accounting team lead asked me to help normalize a huge dataset. Until then my Excel experience was very basic. I knew how to sum columns and maybe write a simple formula, but nothing fancy.
Still, I said yes.
I spent hours experimenting with formulas, cleaning data, and figuring things out step by step.
And somehow, it worked.
By the end of it, I looked like someone who had been doing Excel automation for years — even though I had learned most of it during that task.
That experience reinforced something important for me: sometimes the best way to learn is simply by jumping into the problem.
Moving to the External Project Team
The accounting platform was an internal project.
Later, someone left the external project team, and I was moved there to replace them.
That environment was very different.
The projects were more structured and closer to client work. We used Redmine for project management and SVN for version control. The system architecture involved a multi-tenant database, and our development environment ran inside virtual machines.
At the time, it felt very modern to me — something like an early version of what container workflows later became.
Our team was small: a few developers and one lead developer who also handled project management.
Working on external projects pushed me much further technically. The problems were bigger, the expectations higher, and the codebase more complex.
It was the place where I truly leveled up.
The Technology Question
I genuinely enjoyed working there.
But after a while, I started noticing something: the technology stack was slowly becoming outdated.
In 2020 we were still heavily using CodeIgniter 3 and jQuery. They worked perfectly fine for the projects we had, but the broader ecosystem was moving toward new tools and architectures.
I realized that if I wanted to keep growing as a developer, I needed to start investing time in more modern technologies.
That’s when I began training on Node.js and modern frontend frameworks like React and Vue.
Not because the existing tools were bad — but because staying relevant in tech requires constant learning.
Final Words
Looking back today, that first job meant a lot more than just employment.
It gave me:
- professional discipline
- real production experience
- confidence as a developer
Most importantly, it showed me that being self-taught was not a limitation.
As a final word, a big thank you to Johary and Yves for giving me this opportunity and trusting me when I was just starting.
Without that first step, the rest of the journey might never have happened.