The year I built five projects and remembered two
Second year, I started everything and finished almost nothing. A line-follower, a weather station, a Bluetooth car, a face-attendance script, a home-automation dashboard. Five repos. Two demos. Zero stories I could actually tell in an interview.
The problem was not motivation. The problem was that I picked projects the way you pick snacks — whatever looked good in the moment.
Looking back, the pattern is obvious. Every one of those projects was inspired by a YouTube video I had watched in the previous 48 hours. None of them came from a problem I actually had. None of them were close enough to what I already knew to be finishable in a weekend, and none of them were far enough away to be worth a full month of effort. I was picking projects from the worst possible middle ground.
The three questions I now ask before starting anything
These days, before I touch a breadboard or open a new repo, I ask three things. Does this teach me a skill I do not already have? Will I still care about it in six weeks, when the novelty wears off? Can I explain in one sentence why it exists?
If any answer is shaky, the project usually dies in week two anyway. Better to kill it on day zero than to drag it around for a month.
The 'one sentence' test is the most useful of the three. If I cannot finish 'this project exists because…' without trailing off into 'and also it would be cool if…', the idea is not ready yet. Ideas that survive that test tend to survive the rest of the build, too.
Boring beats clever, almost every time
The projects on my portfolio that actually got me noticed are not the flashy ones. The smart speed breaker won Avishkar not because the idea was novel — speed breakers are old — but because the execution was honest end-to-end: camera, model, actuator, telemetry, dashboard.
Clever ideas get likes on LinkedIn. Boring, finished projects get jobs.
The other quiet advantage of boring projects: they age well. A 'novel' project from two years ago looks dated the moment the underlying trend shifts. A 'boring but solid' project from two years ago still works, still demos well, and still says something true about how you build.
Killing a project is a skill, not a failure
I used to feel guilty about abandoning a half-built project. Then I noticed that the engineers I respected the most were ruthless about it. They would write a one-paragraph postmortem, archive the repo, and move on the same week.
Now I do the same. A killed project with notes is more useful than a half-alive one that haunts your weekends.
The postmortem is the important part. Three honest sentences — why I started it, why I stopped, what I learned — turn a dead project into a permanent asset. Without that, the time is gone. With it, the next decision gets faster.
What I look for now
I look for projects that sit at the edge of something I already know — close enough that I can ship a v1 in a weekend, far enough that v2 forces me to learn something real. ResNet50 on a Pi started that way. So did the piezo harvester.
The rule of thumb: pick projects that make your next project easier. Compounding works in engineering too. The hardware you bring up for one project becomes the test rig for the next. The dashboard you build for one becomes the template for the next. After two or three projects, the per-project setup cost drops dramatically — but only if you are deliberate about reusing what you built.
If you are a student reading this
Pick fewer projects. Finish them. Write down what broke. Show up at one competition a year and let the deadline do the editing for you.
Three finished projects with honest writeups will out-CV ten half-built repos every single time. I learned that the slow way so you do not have to.
And treat your README as part of the project, not an afterthought. The way you describe a project in writing is half of what an interviewer or recruiter ever sees. Spend the extra hour. It compounds for years.