Some of the best engineers I know are tinkerers. They always have a little side project going on - a throwaway prototype, a tiny script, a UI experiment, a new language to poke at. None of it needs to be world-changing. Most of it won't ship. That's the point.

Side projects stretch your instincts in ways your day job rarely does. Work often narrows your focus to a specific stack, a specific product, a specific set of constraints. That's valuable, but it can also put you in a bubble. Tinkering pops that bubble. You get to choose problems that interest you, try tools that don't fit your company's tech stack, and follow curiosity without needing a ticket or a meeting.

When you work on small projects, you practice the full loop more often: ideation, scoping, building, debugging, shipping (or killing), and reflecting. You make decisions faster. You get comfortable deleting code. You learn where you over-engineer and where you cut corners too early. It sharpens your taste.

It also builds range. Mess around with WebAssembly for a weekend, wire up a tiny worker with Cloudflare, sketch a CLI in Go, or design a tiny UI with Tailwind and Alpine. None of this needs to become your new career. But when a problem at work crosses your path - a performance bottleneck, an odd deployment constraint, an unfamiliar protocol - you've already touched the edges. You're not learning from zero.

I love seeing engineers with a trail of small, weird repos. Little experiments. Half-finished ideas. A single-file tool to scratch an itch. That history tells me they're curious, self-directed, and not afraid to learn in public. It's not about stars. It's about reps.

If you don't carve out space for this, your growth tends to mirror your company's constraints. You can become very good at building one kind of thing, in one way. That's respectable, but limiting. The industry keeps shifting - platforms, runtimes, paradigms. Tinkerers adapt faster because they've already practiced changing their mind.

Tinkerers also tune their tools. They change their editor settings, keybindings, theme, lint rules, snippet library, formatter, and even their terminal layout - anything that removes a tiny friction or makes a common action faster. That one popup that breaks your flow? Gone. The default formatting that fights your taste? Fixed. Over time these micro-optimizations add up to real speed and clarity.

Throwing code away is fine. The goal of a side project is learning and judgment, not artifact preservation. If a branch, repo, or weekend prototype taught you something valuable, it already paid for itself. Delete it, keep the notes, and carry the insight into the next thing. Treat throwaways as tuition.

Where to start?

• Pick problems, not technologies. "I want a script that renames photos using EXIF data," not "I must learn Rust."
• Keep the scope tiny. If it takes more than a weekend, shrink it.
• Optimize for learning speed, not architecture purity.
• Ship ugly. Then, if it's still interesting a week later, clean it up.
• Write a short README about what you learned. Future you will thank you.

And if you manage engineers: encourage this. Budget a little time. Celebrate demos. Let people share throwaways without judgment. Teams with tinkerers tend to find better solutions, faster. They bring fresh ideas into the room - and they have the muscle memory to try them.

You don't need permission to be one of these people. Start small. Make something. Break something. Learn something. Then do it again.