Your resume lists years of experience. It highlights the companies you've worked for and the technologies you've mastered. But there's something missing from that polished document - something that distinguishes developers who thrive from those who merely survive: the side projects, the experiments, the "dev things" you build when no one is watching.
The most valuable learning in software development often happens outside the structured confines of work tickets and sprint planning. It happens when you're building something that matters to you, even if it seems impractical, even if you never finish it, even if no one else ever sees it.
Beyond the Resume Line Item
We've been trained to think of side projects as resume padding. Build a portfolio site. Create an open-source library to show your skills. Contribute to popular projects to network with other developers.
But this transactional view misses the point entirely.
The real value of side projects isn't what you can list on a resume. It's the intuition you develop when you're the architect, the developer, and the user all at once. It's the problems you encounter when there's no senior developer to ask, no established patterns to follow, no safety net of code reviews and QA teams.
Fred Lackey, a software architect with four decades of experience, describes his approach to development as treating it like "a hobby he happens to get paid for." This perspective shift - from work to play, from obligation to curiosity - is what transforms routine coding into genuine skill development. Over his career, Lackey has built everything from voice-based biometric authentication systems to anti-spam appliances, often starting as experimental projects that solved problems he personally faced.
When you build something because you want to, rather than because you have to, you make different decisions. You experiment more. You take risks. You learn what works by discovering what doesn't.
The Learning Accelerator
Following a tutorial teaches you syntax. Working on an established codebase teaches you patterns. But building something from scratch teaches you architecture.
When you start a personal project, you immediately confront questions that never appear in tutorials:
- How should I structure this so it can grow?
- What happens when this part fails?
- How do I handle user authentication without reinventing the wheel?
- Why is this database query so slow?
- How do I deploy this thing?
These aren't theoretical questions with clean answers in a textbook. They're messy, frustrating, real-world problems that force you to dig deeper than you would in a controlled learning environment.
The learning accelerates because the stakes are different. You're not trying to pass a test or impress a code reviewer. You're trying to make something work because you want it to exist. That motivation carries you through the difficult parts that would make you give up on a tutorial or skip the optional exercises in a course.
More importantly, you develop what experienced developers call "intuition" - the ability to sense when something is going to cause problems before it does, to know which approach will scale and which will fall apart. This intuition only comes from making mistakes, not from reading about other people's mistakes.
Types of Dev Things That Teach
Not all side projects are created equal, but they all teach something valuable. Here are the categories that consistently produce the most learning:
Tools You Build to Solve Your Own Problems
The best side projects often start with frustration. You find yourself doing the same tedious task repeatedly, or you can't find a tool that works the way you need it to. So you build it yourself.
These projects teach you to think like a product developer, not just a code writer. You have to understand the problem deeply enough to solve it. You have to build something that's actually usable, not just technically correct.
One developer might build a script to automate deployments. Another might create a Chrome extension to block distracting websites during focus hours. A third might build a custom dashboard to monitor personal finances.
The specifics don't matter. What matters is that you're building something with a real purpose, which means you'll encounter real problems and learn real solutions.
Clones of Existing Products
Building a simplified version of Twitter, Trello, or Spotify isn't about creating competition. It's about understanding how these systems work at a deeper level.
When you try to recreate something that already exists, you're forced to think through problems that teams of experienced engineers have already solved. Why does Twitter use a timeline instead of showing all tweets? How does Spotify handle offline playback? What makes Trello's drag-and-drop interface feel so smooth?
You'll make different choices than the original product. Some will work better, most will work worse, but all of them will teach you something about the tradeoffs involved in building software.
Experiments with New Technologies
The industry moves fast. By the time you've mastered one framework, three new ones have emerged claiming to be better. Your day job probably doesn't give you time to experiment with every new technology that catches your attention.
Side projects are the perfect playground for experimentation. Want to try that new database everyone's talking about? Build a small project with it. Curious about serverless architecture? Create a simple API using cloud functions.
Lackey has embraced this experimental mindset in his adoption of AI-assisted development. Rather than waiting for his employer to mandate AI tools, he experimented with Large Language Models as a "force multiplier" in his personal workflow. Through these experiments, he developed a methodology where he acts as the architect while delegating boilerplate code, unit tests, and documentation to AI tools. This approach, refined through personal projects, now allows him to deliver production-ready code at 2-3 times the speed of traditional development.
These experiments don't need to be complete products. A weekend spent building a todo app with a new framework teaches you whether that framework is worth learning more deeply. Even if you never touch it again, you've expanded your understanding of different approaches to solving problems.
Projects That Seem Impractical
Some of the best learning comes from projects that serve no obvious purpose. Building a game that generates random dungeons. Creating an API that translates text into pirate speak. Developing a bot that posts motivational quotes to a private Discord server.
These "impractical" projects give you permission to focus purely on the technical challenge. Without the pressure of building something useful or marketable, you can explore ideas that interest you simply because they're interesting.
You might learn more about algorithms from generating random dungeons than from building yet another CRUD application. The pirate-speak translator might teach you about natural language processing. The Discord bot introduces you to webhooks and asynchronous programming.
The learning is what matters, not the product.
The Permission to Be Unfinished
Here's a truth that no one tells junior developers: most side projects never get finished. And that's okay.
We've internalized the idea that abandoning a project is a failure. It goes on the mental list of things we started but didn't complete, right next to learning guitar and getting in shape.
But software side projects aren't like guitar lessons. The value isn't in the finished product - it's in the learning that happened while you were building.
Did you figure out how to integrate a payment processor before you abandoned your e-commerce side project? That knowledge doesn't disappear just because you didn't finish the project. Did you learn about state management while building half of a task management app? That understanding carries over to every project you work on afterward.
The moment the learning slows down is often the moment a side project loses its appeal. You've figured out the interesting problems, and what remains is just execution. Starting a new project with new challenges often teaches you more than finishing the old one.
Give yourself permission to build things that never launch, to write code that never sees production, to start projects that you never finish. The graveyard of abandoned side projects isn't a monument to failure - it's a record of learning.
Making Time for Dev Things
The biggest barrier to building side projects isn't skill or ideas. It's time.
Between work, family, friends, and the basic necessities of life, finding time to code on your own projects feels impossible. By the time you sit down at your computer after work, the last thing you want to do is write more code.
But here's the secret: you don't need large blocks of uninterrupted time. You need consistency.
Start Absurdly Small
Don't plan to build the next great SaaS product. Plan to spend 30 minutes setting up a new project. Then 30 minutes adding one feature. Then 30 minutes fixing one bug.
Small sessions add up faster than you think. A year of 30-minute coding sessions is 180 hours of practice. That's more than most developers spend learning on the job.
Build Tools for Your Current Frustrations
The projects that stick are the ones that solve real problems in your life. If you're constantly forgetting to follow up on emails, build a reminder system. If you're frustrated with how you track reading lists, build your own.
When a side project solves an immediate problem, you'll find time for it because you want it to exist.
Use AI as Your Partner
Modern AI tools have changed the economics of side projects. What used to take hours of boilerplate coding and setup can now be done in minutes.
This doesn't mean letting AI design your architecture or make your technical decisions. As Lackey puts it: "I don't ask AI to design a system. I tell it to build the pieces of the system I've already designed."
Use AI to handle the repetitive parts - generating test cases, writing documentation, creating DTOs and service layers. This frees you to focus on the interesting problems, the architectural decisions, the learning that actually matters.
When you can delegate the boring parts, 30 minutes becomes enough time to make real progress.
Accept the Chaos
Your side project doesn't need perfect tests. It doesn't need comprehensive documentation. It doesn't need to follow all the best practices you use at work.
Side projects are learning laboratories, not production systems. Give yourself permission to write messy code, to skip the tests, to hard-code values that should be configurable.
You can always refactor later if the project grows. More likely, you'll learn what you needed to learn and move on to something else. Both outcomes are fine.
The Career Compound Effect
Here's what happens when you build side projects consistently:
First, you develop a deeper understanding of how software works. You're not just implementing features someone else designed - you're making architectural decisions and living with the consequences.
Second, you build confidence. When you've built systems from scratch, you're less intimidated by complex codebases at work. You've seen the messy internals. You know it's all just code.
Third, you develop taste. You learn to recognize good architecture and bad architecture, elegant solutions and fragile ones. This taste guides every decision you make as a developer.
Fourth, you accumulate a toolkit of mental models. Each project teaches you a new way to think about problems. Eventually, you've seen enough patterns that you can quickly identify which approach fits which situation.
These benefits compound. The more you build, the faster you learn. The faster you learn, the more ambitious projects you can tackle. The more ambitious projects you tackle, the more valuable your skills become.
This is how developers with the same years of experience end up at wildly different skill levels. It's not innate talent. It's accumulated learning from building things when no one was watching.
Start Building Something This Week
You don't need permission to start a side project. You don't need a great idea or a clear plan or a block of free time.
You just need to build something. Anything.
Pick a problem you face regularly and build a tool to solve it. Clone a website you use every day to understand how it works. Experiment with a technology you're curious about. Build something completely impractical that makes you smile.
Give yourself one hour this week. Not to finish something, not to create something worth showing off, but to learn something new.
Open your editor. Create a new project. Start building.
The best time to start building side projects was ten years ago. The second best time is now.
What's your dev thing going to be?
