The first year was just demos
Early on, every project was a demo — wire it up, get the LED to blink, screenshot it, move on. It looked productive but I was not building anything I could come back to a month later.
The code was throwaway, the schematics lived in my head, and the bugs always came back. The repos on my GitHub from that period look impressive on a count basis and embarrassing if you open any of them. Lots of starts, very few finishes.
The internship that changed how I debugged
My embedded systems internship at Emertxe was where 'debugging' stopped meaning 'add more print statements' and started meaning 'form a hypothesis, isolate the variable, verify with the right instrument.'
Reproducing and documenting 10+ defects with proper step-by-step troubleshooting forced a discipline I did not have before. UART log analysis became second nature. So did the habit of writing the bug down before fixing it.
The shift was uncomfortable at first. Slowing down to write 'expected vs actual' before touching the code felt like a waste of time. Then it stopped feeling that way, because the bugs I had been chasing in circles started getting solved on the first attempt.
Competitions teach scope control
Avishkar, IETE events, NEON workshops — competitions all have one thing in common: a deadline you cannot move.
That deadline kills feature creep faster than any senior engineer ever will. You learn to ship the boring 80% that works instead of the exciting 20% that demos well and falls apart on stage. By the third competition, I had stopped designing for the demo and started designing for the recovery — what happens when the live demo breaks, and how fast can I get it back. That mindset shift outlived every project I built for those events.
Documentation is a love letter to your future self
The single highest-ROI habit I picked up was writing a short README for every project before I started, and a shorter retrospective after I finished.
Six months later, when someone asks 'how did you build the speed breaker?', I do not have to reconstruct it from memory. The notes are right there. Past me did present me a favor.
The retrospective matters as much as the README. Three lines is enough: what worked, what did not, what I would change. Read them before starting the next project and you stop repeating the same mistakes. Skip them and you definitely repeat them.
Mentorship makes you faster than you can be alone
Teaching juniors at NEON TCOER taught me to articulate things I had only intuited. Being mentored by seniors at the internship gave me a vocabulary for problems I had only felt. Both directions of the mentorship loop made me faster than any solo grinding ever did.
If you are a student reading this, find both. A junior to teach and a senior to learn from. Do not wait until you 'know enough' to teach — you already know enough for someone who started a year after you.
What 'thinking like an engineer' actually means
It is not the tools — anyone can install TensorFlow or wire an Arduino. It is the loop: define the smallest useful version, build it, measure it honestly, kill what does not work, document what does, repeat.
Three years of student projects taught me that the loop matters more than the language, the framework, or the chip. The tools will change every two years. The loop is the thing that compounds across a career.