What I Learned Shipping 4 Projects as a Student

Shipping Is a Skill

In college, you learn to write code. Nobody teaches you to ship code. These are fundamentally different skills. Writing code is about solving a problem. Shipping code is about solving a problem well enough, fast enough, for a real user, with all the boring stuff included — error handling, edge cases, deployment, documentation.

Over the past two years, I built and shipped four production-quality projects: FarmAssist (IoT + Edge ML), an Intelligent File Integrity Monitor, a Harmonica Tab Generator, and a Learning Operating System. Each one taught me something that no textbook covered.

Lesson 1: Scope Creep Is the Default

Every project started with a clean specification and ended up three times larger. FarmAssist was supposed to be a sensor dashboard. Then it needed ML classification. Then multilingual support. Then market price integration. Then weather APIs.

The fix wasn't saying "no" to features — it was sequencing. I learned to define a Minimum Viable Product ruthlessly, ship it, then iterate. Every feature after MVP gets evaluated against: "Does a real user need this right now?"

Lesson 2: Premature Optimization Is Real

On the File Integrity Monitor, I spent a week building a custom event batching system to handle "millions of filesystem events." In reality, the system monitored a few hundred files. The simple approach — process each event individually — had zero performance issues.

I now follow a strict rule: measure before optimizing. If you can't show me a profiler output or a metric that proves this is slow, we're not optimizing it.

Lesson 3: The Last 10% Takes 50% of the Time

Getting a project to "it works on my machine" takes 50% of the effort. Getting it to "it works reliably for other people" takes the other 50%. This includes:

• Error handling for inputs you didn't think of
• Loading states, empty states, error states in the UI
• Environment configuration and deployment scripts
• Documentation that explains not just how but why
• Testing the unhappy paths, not just the happy ones

The Harmonica Tab Generator worked beautifully on clean studio recordings. It fell apart on phone recordings with background noise. Adding audio preprocessing (noise reduction, normalization) was "the last 10%" that took three weeks.

Lesson 4: Boring Technology Wins

For every project, I was tempted to use the newest, most interesting technology. GraphQL instead of REST. Svelte instead of React. A novel database instead of MongoDB.

I learned to resist. Boring technology has better documentation, larger communities, and known failure modes. When something breaks at 2am, you want Stack Overflow answers, not GitHub issues with "me too" comments.

Use proven tools for the foundation. Save the experimentation for the parts that are genuinely novel — the edge ML inference, the behavioral anomaly detection, the AI-driven curriculum planning. Those are where innovation creates value.

Lesson 5: Write About What You Build

The act of writing about a project forces you to understand it more deeply. When I wrote the blog post about my edge-vs-cloud architecture decision, I realized there were tradeoffs I hadn't fully considered. Writing surfaced gaps in my thinking that building alone didn't.

Writing also compounds. Every blog post is a permanent artifact that communicates your thinking to people you'll never meet. It's the highest-leverage activity an engineer can do outside of building.