Learning in public, and what four years of it actually taught me
I started my degree assuming there was an order to things — that you learn the theory, pass the exam, and then you are allowed to build something. Four years and one graduation later, I think that order is backwards.
Build slightly past what you know
Every project that taught me something was one I was not quite qualified to start. The retrieval system meant learning about embeddings while writing the code that used them. The Flask API meant learning what REST actually promises, not just which decorator to type.
The gap between “I can follow this tutorial” and “I can debug this at midnight when it breaks” is where the learning lives, and you cannot get there by reading.
Competitions are a deadline, not a verdict
Two of the more useful things I did were contests — an innovation contest at IIT Kharagpur, and a Science Day model called EcoFlow Irrigator. We placed third in both.
Third place is a good teacher. You are close enough to see exactly what the better entries did differently, and far enough away that you cannot pretend you had already thought of it.
What the deadline really bought was a forced ending. A project with no deadline stays 80% finished forever.
The unfinished ones still counted
My repositories are not a gallery of triumphs. There is a game I wrote to understand event listeners, CRUD endpoints I built to understand what a framework was doing on my behalf, and several things that never worked at all.
The ones that failed still moved something. You do not get to choose which attempt teaches you the thing.
What changed once it became a job
Working as an engineer rearranged my priorities more than I expected. At university the hard part was making something work at all. At work the hard part is making it work for someone else — predictably, next month, when I am not the one running it.
The habit that transferred cleanly was the one I picked up building side projects: write down what broke and how you fixed it. Everything else I am still learning.
What I would tell first-year me
- Read other people’s code far earlier than feels comfortable.
- A working ugly version beats an elegant plan.
- Ask the question in the group chat. Everyone else is confused too.
- The thing you build badly this month is the reason you can build it well next year.
got thoughts?
Let's talk