A three-year path through self-study, a first job, and a return to AI. What I’d tell someone starting now.

Three years ago I wrote my first line of code. Today I work as a remote contractor building AI products, and I spend my free time studying ML from the ground up. Before code, I spent seven years producing music, and one track I mixed hit 200k plays on SoundCloud. I taught English on the side to pay my way through learning to program. None of this was a plan. This is how it actually happened.

Before code

I started making music as a teenager. Rap, hip-hop, R&B, mostly in a group with friends. I wrote, recorded, and mixed everything myself, and pretty much all of what I knew about mixing came from one course on YouTube. The rest was just practice. One of my own tracks got 20k plays on SoundCloud, and another one I mixed for someone else passed 200k. That person later got popular on TikTok.

I did this seriously for a few years before my interests started pulling elsewhere. Music was the thing for me, but computers had always been around in the background too. Games, messing with software, general curiosity. Underneath all of it was something simpler: I liked making things. Music was one way to do that, and at some point I started to feel there were others.

Two things from those years turned out to matter later. The first was how I learned. One course to get oriented, then practice as the actual teacher. I didn’t know it was a method at the time. It was just what worked.

The second was a way of thinking about work. A song isn’t a list of features, it’s one thing that either lands or it doesn’t. Most of mixing is about getting the parts to sit together and making them work as one thing instead of a collection of tracks. That turns out to be most of engineering too. You can have clean code, good architecture, and the right library choices, and still ship a product that doesn’t work, because the parts don’t talk to each other the right way. There’s also a creative side to it: problem-solving as a craft, not a procedure. I didn’t see any of this coming at the time, but the instinct was already there.

The decision

In 11th grade a friend showed me plain HTML. No CSS, just tags. Something about it clicked, and for the next few days I went around telling family and friends that I could make a page, write anything I wanted on it, and it would just be there. I was in a math-focused class, and we had a decent computer science teacher who was an actual programmer. He once explained what an algorithm was in a way I still remember. None of that had made me want to code, though. Programming in school was dry, but HTML wasn’t. You made a thing, and the thing existed.

I didn’t act on it then. It sat in the back of my head for about a year.

I started coding seriously a few years ago. The war was on, I was about to start university, and I wanted work that didn’t tie me to a location, so I could go where I needed to go. The thought arrived simply: I’d try coding for real, the thing I’d dismissed in school before someone showed me what you could actually build with it. The reasoning wasn’t poetic. Programming had the highest earning ceiling I could see, and it interested me. That was enough.

I started with a Python course on YouTube and FreeCodeCamp’s Python track, and the internet became my real teacher. Everything that mattered, including the habit of actually sticking with things, I had to build on my own.

How I paid for it

I taught English on the side. I’d been learning the language since school, and while I had a tutor who pointed me in the right direction, maybe 80% of it was on my own. Books, shows, talking to people online, stumbling through conversations until they stopped being hard. By the time I started coding, I was good enough to teach it.

I ran the teaching myself. Found students through Telegram, Facebook, and word of mouth. I did one-on-ones, group classes, and speaking clubs, and I capped the clubs at four people because that was the sweet spot for actually getting everyone to talk. At the peak I was teaching around 20 hours a week across adults, teenagers, and kids, and I was running all of this alongside coding three to six hours a day.

I didn’t just teach English, I taught people how to learn. Comprehensible input, spaced repetition, the idea that understanding comes before production. A lot of my students had tried to “study” English for years without getting anywhere, and what they actually needed was a method that respected how languages go into your head. Teaching that well turned out to be more valuable than teaching grammar.

I kept doing this for about three years, including into my first developer job whenever time allowed. Eventually I wound it down to one remaining student, a kid I teach programming to now, because I wanted to put everything I had into AI.

But if I’m being honest about what teaching gave me beyond the money, it was one thing: communication. Communication, communication, communication. Explaining something to a ten-year-old, to a forty-year-old, and to yourself at 2am when you’re stuck on a bug are closer skills than they look.

How I actually learned to code

The path I took looks linear in retrospect. It wasn’t, but the resources I used worked. I started with Python through a YouTube course and FreeCodeCamp’s Python curriculum, and from there I went into CS50. I did the first five weeks, up to the point where the course transitions into JavaScript, which took me about a month. By then I’d figured out something important: I wanted to build things, not analyze data. Data science had been on the table because I was interested in AI, but the day-to-day of engineering pulled harder, so I switched tracks.

From CS50 I moved to The Odin Project and worked through it up to the React module. After that I went into Full Stack Open, the University of Helsinki’s open course, and completed through part 7 plus a few of the later parts on specific topics. That was most of my stack: JavaScript, React, Node, the way real web applications are put together.

Projects were baked into the courses, so I didn’t have to invent side projects to practice on. I just did what each curriculum asked and built each thing properly instead of skimming. Algorithms and data structures were the part that took the most thinking, but everything else moved.

I didn’t take notes, and I didn’t have a system. When I didn’t fully understand something, I’d go back and watch or read it again until it clicked. That was the whole method. Three to six hours a day, most days, for months.

People ask me about motivation and how I kept going through all the learning. The honest answer is that learning itself wasn’t the hard part for me. I liked it. Most days I didn’t have to push myself into the chair, I was already in it. That doesn’t mean the path was easy, the hard part came later, once I had a job. But the self-study months were something I mostly enjoyed, and I think that’s closer to luck than to discipline. If coding hadn’t clicked the way it did, I’d be telling a different story.

The first job

Six or seven months into self-study, I started looking for a job. I’d later learn that finding one was the easier part. I used job boards, Telegram channels, and a local IT job aggregator. Two or three months of applications while still learning. There’s a detail from that period I still laugh about: I put the wrong phone number on my resume for weeks before I noticed. Somehow people still got in touch.

The first real process I went through was for an OSINT product in cybersecurity. The take-home was to build a resume builder in Vue, and I hadn’t learned Vue. This was late 2022, before ChatGPT was a thing you could lean on, so I read the docs and figured it out as I built. Three days later I had a working first version. Then came a three-hour live interview in English with live coding, a follow-up round with more code, and two offers. One the next morning, one a day after. I took the first.

The job itself was harder than I expected. The stack was pure JavaScript with web components, plain Node, and raw SQL. I hadn’t written web components or real SQL before, so I learned both on the job, under actual deadlines, on a real product. This is where the gap between self-study and production work shows up. In courses everything is designed to be learnable in the order it’s given, but in a real codebase you’re dropped into the middle and expected to figure out how the parts connect while also not breaking anything.

There were months where I genuinely thought coding might not be for me. The difficulty wasn’t any single concept, it was the constant background pressure of being the least experienced person in every conversation. I had a mentor, and honestly he was the reason I stayed. He didn’t just answer questions, he taught me how to think about systems, how to break work into milestones, and how to plan before touching the keyboard. That shift in thinking was worth more than any piece of syntax I learned there.

I stayed about a year, and then left to join somewhere else with a different stack and more varied work. The honest takeaway from that first year wasn’t technical, it was that I wanted more control over what I worked on and how I worked. That realization is what eventually pushed me toward contracting instead of full-time employment, but that’s a later chapter.

Back to AI

I didn’t plan to come back to AI specifically. It happened because the world changed.

Late 2022 and through 2023 was when things that used to be science fiction became regular Tuesday conversations. Models could write, reason, translate, and code. The ceiling of what a computer could do moved in a way I’d never seen happen to any technology in my lifetime. I’d originally been pulled toward engineering because it felt more tangible than data science, and now tangible and AI were suddenly the same thing. I wanted to understand how the new stuff actually worked, not at the level of “I know how to call an API” but underneath.

I started working through the foundations in parallel to my day job. Andrew Ng’s ML course on Coursera, with the practical scikit-learn side. Grokking Deep Learning. Fast.ai Part 1. Daniel Bourke’s PyTorch course. Khan Academy for the statistics I needed. And then Karpathy’s Zero to Hero, which is probably the single most valuable thing I’ve watched on this topic. Building a language model from scratch, including manually writing the backprop, is a completely different experience from reading about it. Right now I’m on Fast.ai Part 2 and Chip Huyen’s AI Engineering, with a personal project on the side.

All of this was happening after work. Three hours most evenings plus time on weekends. That’s been the pattern for a while now.

AI also found its way into my day-to-day work naturally. I’ve been designing LLM integrations, building caching strategies around model calls, setting up evaluation pipelines to measure whether a model change actually helps or quietly regresses something, and working on fine-tuning diffusion models. What I’ve found so far is that most of the interesting problems aren’t about picking the right model. They’re about knowing whether your system is actually working, catching silent failures, and keeping costs sane at scale. Those feel like engineering questions more than research questions, at least in the work I do.

The reason I keep going deeper, reading the book, writing the backprop by hand, actually learning the math, is simple. I want to understand things, not just use them. Using AI without understanding it feels unfinished to me. You can get away with surface-level for a while, but you hit a ceiling early, and you can’t fix what you can’t see. I’d felt something similar before in other things I’d learned, where shallow gets you started but never gets you all the way, so it was a familiar instinct more than a new one.

Where I am now

I’m still in the middle of this, not at the end of it. I work as a remote contractor on AI products, and I’m learning deeper into ML in parallel. I don’t have a specific next course plotted out. I want to understand business, product, and the technical side together, not pick one and narrow. Right now the work I do and the things I learn match up, and that’s enough.

If anyone reads this and wants a rough roadmap, here’s what actually worked for me, stripped of anything that wasn’t real:

• Start with what interests you, not what’s optimal. I went into coding because HTML blew my mind, not because someone ran the numbers on software salaries. Interest compounds into hours in the chair. Optimization doesn’t.

• Use courses, don’t worship them. I didn’t finish any of the big courses I started. I went through CS50’s first five weeks, stopped when it transitioned to JavaScript, and moved to The Odin Project. I worked through Odin up to the React module, then switched to Full Stack Open for part 7 and a few parts after. Each switch happened when the course had given me what I needed for the next step. The point isn’t to complete curricula, it’s to build a stack you can actually work with. Staying on a course past that point is just a way to feel productive while not moving.

• Use what you already have. Before I started coding, I had seven years of teaching myself music and a few years of teaching myself English well enough to teach others. I didn’t see either of those as career assets at the time, they just happened to be things I did. But both of them gave me something I’d need later: a way of learning alone, and the discipline to practice without anyone watching. Look at what you’ve already spent time on and figure out what it actually taught you. Some of it will transfer. Strong backgrounds don’t need to be technical to matter.

• Take the first real job that’ll have you, not the best-sounding one. The company name barely matters at the start. What matters is being surrounded by working code and people who’ve seen more than you have. I had a good mentor at my first job and I’d trade most credentials for that tradeoff again.

• Make it a habit, not a motivation problem. Three to six hours a day for months wasn’t an act of willpower, it was just what I did. Once it’s the default, you stop negotiating with yourself about it.

• Pick something you actually enjoy. This sounds obvious but it isn’t. If every day feels like force, you’re either in the wrong field or haven’t found your specific part of it yet. I got lucky with code. Not everyone clicks with their first choice, and switching is fine.

Would I do anything differently if I started over? Honestly no, I’d do it the same way, and that’s probably the most honest thing I can say about any of this.

If you’re on a similar path or have questions, reach out. I’m happy to talk.

— Filip