Why I Started nandy.triesthings
Learning computer science by trying, breaking, and fixing things in public
(and Why I’m Posting the Messy Parts)
Most tech blogs start after things work.
This one starts before that.
I created nandy.triesthings because I’m tired of only seeing polished end results — perfect architectures, clean diagrams, and “lessons learned” that skip the confusion, the broken builds, and the why-is-this-not-working moments.
This blog is about the act of trying.
Sometimes things work.
Sometimes they break.
Most of the time, they teach me how to be a better human and a better engineer.
And I want to document all of it.
Why “tries things”?
Because that’s what real learning in computer science looks like.
Not:
“I followed a tutorial and it worked.”
But:
System Resilience: Troubleshooting production servers and finding the "glitch" that reduces downtime.
The Scripting Struggle: Staring at stack traces only to realize an automated reporting script failed because of a single typo.
The Learning Curve: The messy process of moving from "understanding concepts" to mastering Python syntax.
That friction is the actual process — especially in areas like cloud, systems, DevOps, and ML.
So instead of pretending I have everything figured out, I decided to build in public.
What I’m Trying (Right Now)
I’m currently finishing my Master’s in Applied Computer Science at Concordia, and my “trying” has naturally pulled me toward MLOps and security.
Here’s what’s actually on my screen these days:
Cloud-native ML experiments: building with Docker, FastAPI, and Uvicorn, and deploying models on AWS
Code rehab: solving one NeetCode problem a day to strengthen my Python and data structures fundamentals
French (B1): navigating the messy, humbling process of learning a new language through government part-time studies
Movement & flow: practicing what I call the happy glitch — growth through dance, fitness, yoga, and showing up consistently
Not everything connects neatly. That’s kind of the point.
Why I’m Posting the Messy Parts
Because the messy parts are where the value is. As an R&D Engineer, I learned that engineering isn't about being perfect; it's about being resilient and adaptable.
When something fails, I want to answer:
What did I think would happen?
What actually happened?
Why was my mental model wrong?
What would I do differently next time?
If this helps someone else avoid the same mistake — great.
If it only helps future me — still worth it.
Who This Is For
This blog is for:
Students building projects and feeling behind
Early engineers who feel like everyone else knows more
Anyone who learns best by trying, breaking, and fixing
It’s also for recruiters or engineers who want to see how I think — not just what I ship.
What’s Coming Next
Next up: Documenting the struggle of cloud-native deployment and the inevitable IAM permission errors that come with MLOps on AWS.
If you’re also trying things—welcome to the mess.
Welcome to nandy.triesthings.
