The career roadmap I never followed

"Sir, what should I learn?"

I heard some version of that question a dozen times at the Notion Community session at VIT Bhopal. The one that stuck with me was the oldest one in the book: "Should I focus on DSA or development?"

As if you have to pick a side before you're allowed to start.

Here's the uncomfortable truth: I don't know. And I'm fairly sure nobody who answers that question confidently does either.

Because I was that student once. At 19 I was asking the same question, just with different nouns in it. And the career I ended up with didn't come from getting the answer right. It came from never really waiting for one.

The roadmap, in hindsight

If you plotted my path on a chart, it looks deliberate:

• 2016: Porting Sailfish OS to a Redmi 2. Android kernels, device trees, vendor blobs.
• 2018: Starting codeIndore(), organizing my first hackathon at 19, becoming a GitHub Campus Expert and teaching Git to anyone who'd sit still.
• 2019: Co-organizing GDG Indore, including DevFest'19 for 400 developers.
• 2020: Becoming CTO at Metafic, and helping scale it past 300 people over the next three years.
• 2024: Starting Leadnics.
• 2025: ISB Hyderabad's IVI venture program, and joining the board at Thinqzo.

It looks like a plan. It wasn't.

Nobody told me that porting an operating system to a phone that didn't need one would teach me how systems actually fit together. Nobody told me that organizing hackathons was, secretly, practice for running engineering teams. I didn't know. I just built the thing in front of me, and each thing made the next one possible.

The roadmap appeared afterwards. It always does.

Why "what should I learn?" is the wrong question

"What should I learn?" assumes learning comes first and building comes after. Collect enough skills, then you're allowed to make something.

It works the other way around. You pick something you want to exist, and you start. The moment you get stuck, you know exactly what to learn next, and you learn it faster than any course could teach it to you, because now it matters.

A student who has built one ugly, working, deployed thing knows more about software than one who has finished three courses on it. Every time.

My version of this was the Redmi 2 (the Wingtech WT88047, if you speak codenames). I wanted Sailfish OS running on a phone it was never built for, and no course on earth teaches you that. So I learned kernels, device trees and vendor blobs one broken build at a time. The phone stopped booting, and I had to flash recovery all over again after a restore. SurfaceFlinger was running happily while the display showed absolutely nothing. FM radio didn't work, and when I finally fixed it, Bluetooth stopped working. So I fixed Bluetooth, and FM broke again. Fix FM, lose Bluetooth. Fix Bluetooth, lose FM. For a while, that loop was the whole job.

But the real lesson wasn't technical. It was about resources. I was syncing an Android kernel tree over git on a slow connection with a tiny data allowance. I didn't have enough CPU cores for fast kernel builds, so every change meant waiting hours before I knew whether it had worked. When one mistake costs you an evening, you learn to read the code twice and think before you hit compile.

I never "studied" operating systems. I just refused to let one phone win.

So the better question is: what can I build?

What I actually look at

This came up a lot at VIT, because a lot of students wanted internships. I couldn't offer one to everyone, but I'm going through every profile that was shared with me and sending personal feedback.

When I look at a student's profile, I'm not scanning for the right keywords. I'm looking for one thing:

What have you built when nobody was paying you to build it?

• A GitHub repo with commits spread over weeks, not one giant upload the night before an application.
• A project that solves a problem you actually had.
• A README that explains why the project exists.
• Proof you finished something. Shipped beats perfect.

None of that requires permission, a degree, or an internship. Which is the point.

So what should you do?

Build something. Something small, something slightly beyond you, something you'd actually use. Put it on GitHub. Write down what broke.

Then build the next thing.

You won't know where it's going. I didn't. But hey, that's the part nobody puts on the roadmap: you can only draw it looking backwards.

P.S. If you're 19 and reading this at 2 AM, go build something.