I didn't want anyone to guide me. I had Stack Overflow in my hand, and I just wanted to learn that way.
I'm a practical learner. I love building and experimenting. The idea of sitting down to learn how to build a scheduler or following standard tutorials step-by-step felt like "other work"—someone else's idea. There's no creativity in that, no real creation.
I only learn a tool when I actually need to use it. That's how it sticks.
Take a simple example: I learned Python's functools.partial because I was working on something and realized I needed a function that could take just one parameter for now, so that after binding, the flow would be clean. I googled it, found partial, and used it. That way, the concept is wired to a story forever, instead of being a dry syntax block in a programming book. Even if I do read and come across a new tool later, it instantly changes my old code in my head; I can immediately think of a project I built where I could use it.
The love, time, and effort I put into each thing I build is impeccable. I dive straight into code because that's how I learn—by my own will, exactly when I need it. You fail, you learn, and sometimes you actually discover things on your own. The high-school scripts I wrote back then—which you'll see below—were primitive, but they were the sparks of a fire I had to build with my own hands. They are the artifacts of my journey, not the limit of my code today. Please don't judge my current engineering standards by them! :)
The Helicopter Fan, Ubuntu, and Playful Automation
My migration to Linux started because my laptop was lagging horribly (especially disk operations). On top of that, my Dell Inspiron 15 fan made a weird, deafening sound—almost like a helicopter. I assumed the disk was dead, did some research, and thought: let's try Ubuntu, it will be a fun experience for no reason.
I dual-booted it. The system was buttery smooth and rarely heated up, which meant the fan barely ever spinned. (Later, I found out it was a hardware fan issue and replacing the physical fan fixed it, but by then I was already hooked on the Unix style of design).
I was fascinated by how people navigated using the command line. I discovered bash, started searching for tools on Stack Overflow, and realized how much better it is to customize your setup, write custom aliases, and chain tools together. I was always confused when I heard about people taking courses to learn Linux/Unix CLI. I just learned it for fun to automate my own stuff.
And when the pandemic hit, with nothing to do, I started trying all kinds of random projects.
At school (Budhanilkantha School), we were allowed laptops but no phones or SIM cards. Laptop notifications were terrible, and I usually kept it on mute or plugged in. But cricket is way too long to sit and watch when exams are nearing. I wanted custom sounds—specifically a different sound for a wicket, a six, or a four—so I could hang out with friends in the dorm room and know exactly when an interesting moment happened.
So, I built a cricket web-scraping bot.
Looking back, that bot was the first time I realized how writing messy code early on teaches you lessons you never forget. My initial scraper just pulled the webpage content every single second. It had zero state tracking or data validation. A data point would show up, then disappear on the next pull, and the bot would freeze or crash constantly. Facing those bugs taught me more about real-time sync, data validation, and handling unpredictable network states than any textbook could. Now, when I write code, a warning triggers in my brain to prevent those exact issues. It's like a pre-trained transformer picking up tiny patterns!
I also built an A-Level SUVAT (physics equations of motion) calculator. In physics, solving the SUVAT equations was just a tiny, boring step at the end of a much larger calculus problem. It felt like wasting time on basic multiplication when I wanted to focus on the calculus. I didn't know about libraries like sympy then, so I wrote my own solver. The code was junk, messy as hell, and relied on evaluating string equations dynamically, but it did the job:
# A snippet of my high school physics.py solver. Messy, but it worked!
def main(s,u,v,a,t,to_find,known_quantities):
formulas=[['U = ((s-((1/2*a)*(t**2)))/t)', ['s','a','t']],
['S = u*t+1/2*a*t**2', ['u','t','a']],
['T = eqn(1/2*a,u,-s) ',['a','u','s']],
['A = 2*(s-u*t)/t**2', ['s','u','t']],
['V = (pow(u**2+round(2*a*s,3),(1/2)),-pow(u**2+round(2*a*s,3),(1/2)))', ['u','a','s']],
['U = (pow(v**2-2*a*s,(1/2)),-pow(v**2-2*a*s,(1/2)))', ['v','a','s']],
['S = (v**2-u**2)/(2*a)', ['v','u','a']],
['A = (v**2-u**2)/(2*s)', ['v','u','s']],
# ...
['A = -2*(s-v*t)/t**2', ['s','v','t']]]
missing=[]
for formula in formulas:
not_given=[null for null in formula[1] if null not in known_quantities]
missing.append(len(not_given))
for formula in formulas:
not_given=[null for null in formula[1] if null not in known_quantities]
if formula[0][0].lower() in to_find:
if set(formula[1])<=set(known_quantities) or len(not_given)<=min(missing):
print(f'Formula required is: {formula[0]}')
if not_given:
print(f'\tNOTE: Supposing {not_given} = 0')
try:
exec(formula[0])Going Deeper into the OOP Rabbit Hole
My obsession with programming language design started when I read about how in Python, everything is an object—even numbers are just instances of the class int as shown by type(1). It was fascinating.
Since I was learning about BNF (Backus-Naur Form) in my A-Level theory class, language grammar became a massive rabbit hole for me. I wanted to see if I could write my own grammar rules. I found an article about adding a custom do-while loop to Python 3.9. I downloaded the source code, hacked the compiler, and completely broke Python for hours before finally getting it to work.
While down that rabbit hole, I came across this bookmarked Stack Overflow post: What are metaclasses in Python?.
I read the top community answer and it blew my mind:
It's because the function type is in fact a metaclass. type is the metaclass Python uses to create all classes behind the scenes.
Woh. That was absolutely fascinating. To people who have never looked into Python internals, it might seem like nothing. But learning about the Method Resolution Order (MRO) and how type creates classes behind the scenes completely reframed my view of OOP. Building a programming language is a massive task, but even just being able to understand the design choices of one felt like a blessing. It changed how I viewed language design forever.
From Hacking to Systems Engineering
This hands-on loop—building something messy, breaking it, hitting a wall, and then searching for the underlying theory to solve it—became my core learning process.
When you run into the physical limits of simple scripts, you are forced to ask why things behave the way they do. That is when theory becomes exciting. Instead of learning systems engineering in a vacuum because a textbook tells me to, I learn it because I need to solve audio latency issues, or because I want to bypass serialization formatting over LLM APIs.
Today, my work spans low-level compilers, high-performance web systems, and audio processing—but the underlying spark is exactly the same as when I built my cricket scorer.
Coding in the Age of AI
I'll admit, I feel a deep nostalgia for the "old way" of coding—back when it was just me, a local editor, and Stack Overflow. "Vibe coding" with AI prompts might be fast, but it can never replicate the sheer adrenaline rush of spending hours debugging, discovering the solution yourself, and writing every line with your own hands. Now, with AI automating everything, it feels like you're forced to use it just to avoid falling behind. But I still make time for fun projects on my own, entirely offline, just for the love of the game.
For example, I really want to build a custom Version Control System (VCS) for students. It's a fun idea: instead of dry Git commits (which even big tech companies are moving away from for custom internal solutions), I want to create a storytelling editor. Every code change can have a note or a story associated with it, recording your intuition, your thought process, and your brain's working. That is what actually makes a developer special—their ability to think through problems.
I've also had to grow as a developer. I used to be a quiet, shelf developer. I hated working with others because they weren't in my line with my speed and knowledge, and just every code felt bad. But as my friends became good developers, I became a much more social developer. I've realized how much fun it is to share ideas, review architecture, and build alongside people who match your frequency.
This blog is my way of keeping that game alive. Thanks for reading.