Side Projects That Teach Skills

Ayesha Raza spent six years as a user experience designer at a large financial services company. Her daily work was competent and well-compensated, but it was also narrow: variations on the same design patterns, using the same Figma templates, for the same category of banking products. On evenings over six months in 2019, she built a browser extension that visualized her own browsing habits as an interactive heat map -- which sites she visited, at what times, for how long, and in what sequence throughout the day.

The project was technically modest and professionally invisible. It forced her to learn JavaScript at a meaningful level for the first time, design data visualizations from first principles without a design system to rely on, and solve UX problems for a product she was building entirely alone. Six months later, she interviewed for a design-engineering hybrid role at a health technology startup. The browser extension -- not her six years of professional portfolio -- was what the interviewers wanted to discuss for most of the interview.

The pattern Raza's experience illustrates is not unusual. Side projects that teach skills frequently do more for professional development and career positioning than equivalent time invested in professional work, for a reason that becomes clear once stated: professional work is optimized for the organization's outcomes within familiar constraints. Side projects are optimized for learning, which means they routinely expose builders to uncomfortable unfamiliarity, complete ownership of every problem, and feedback from real use rather than organizational approval.

The Distinction Between Learning Projects and Productive Busy Work

Not all side projects teach meaningful skills. The critical distinction is whether the project pushes you into genuinely unfamiliar territory or allows you to repeat familiar patterns in slightly different contexts.

A web developer who builds a tenth personal website using the same technology stack and similar architectural decisions is doing productive busy work: it takes time, produces output, and feels creative, but it does not build new capabilities. The same developer who builds a command-line tool, a machine learning pipeline, or a mobile application using a different programming paradigm is in genuine learning territory, because each requires solving problems that familiar approaches cannot address.

Psychologist Lev Vygotsky's concept of the zone of proximal development -- the region between what a learner can do independently and what they can only do with assistance -- identifies the productive difficulty level for learning. Work entirely within existing capability produces no learning; work entirely beyond current capability produces only frustration. The zone in between -- challenging enough to require growth but not so far beyond current ability that progress stalls -- is where skill development actually happens.

The practical test: are you getting stuck regularly? Getting stuck means encountering a problem you cannot solve with your current knowledge, which requires learning something new to proceed. A project on which you never get stuck is a project that is not teaching you anything new. A project on which you are permanently stuck is a project that has exceeded the zone of proximal development and needs to be rescoped.

Project Characteristic Learning Value Busy Work Indicator
Uses at least one unfamiliar tool or technique High Exclusively familiar tools throughout
Requires solving problems you have not solved before High Reapplies known solutions to new contexts
Produces something that works in real conditions High Works in tutorial environment, never deployed
Involves multiple iterations after user or self-testing High First version is final version
Forces engagement with failure and debugging High Clean path to completion
Generates output you can show or use High Output is disposable immediately after building

Project Category: Build Something You Will Actually Use

The highest-leverage side project category is the one most directly connected to the builder's actual life: tools that solve problems the builder personally experiences. Personal budgeting dashboards, reading tracking systems, task automation scripts, custom notification systems, or specialized data monitors -- projects where the builder is also the user combine genuine motivation with a real-world feedback mechanism that is unavailable in any other project category.

The built-for-yourself constraint solves two of the most common side project problems simultaneously. The motivation problem is solved because you are working on something that matters to you specifically, not an abstract exercise. The feedback problem is solved because you use the thing you built and immediately discover what does not work, what is missing, and what is more complicated than anticipated.

The built-for-yourself project also provides an implicit product management education. You must prioritize features under time and energy constraints. You must make design tradeoffs between simplicity and capability. You must decide when to stop adding features and start using what you have built. These decisions, made under real constraints with real consequences, develop judgment that tutorial projects cannot.

Example: Pieter Levels (known online as @levelsio) has built more than seventy projects since 2014, most of them tools solving problems he personally encountered as a location-independent software developer. NomadList, which ranks cities by internet speed, cost, weather, and quality of life for remote workers, was built because Levels himself needed a way to choose where to live and work. The site generated approximately $50,000 per month within its first year, not because it was technically sophisticated -- it was built in a weekend -- but because it solved a real problem for a real user who happened to be the builder. The approach is not a business strategy in the first instance; it is a learning strategy that happens to produce products worth using.

Project Category: Recreate a Simplified Version of Something You Use

Building a stripped-down version of an existing tool or application teaches more about software design than most formal coursework because it requires understanding the decisions behind features that users experience as natural and obvious.

Real-time collaboration in Google Docs requires conflict resolution algorithms, distributed state management, and operational transformation -- problems invisible to users but visible to anyone who tries to build something similar. Full-text search in a note-taking app requires indexing, query parsing, and relevance ranking -- trivial to use, non-trivial to implement. The notification system in any modern app requires understanding user state, delivery reliability, and preference management across devices.

The clone project does not aim to produce a competitor. The goal is understanding. Building a minimal version of Trello teaches everything the builder needs to know about state management for drag-and-drop interfaces. Building a minimal version of a Markdown editor teaches the basics of text parsing, rendering pipelines, and editor state. Building a minimal version of a search engine teaches indexing strategies and relevance ranking. The learning is in the implementation, not in the production quality of the result.

Example: The Recurse Center, a programmer retreat in New York City founded in 2011, has documented that one of the most consistently high-learning project types for participants is the "from scratch" reimplementation: build a database engine, build a programming language interpreter, build a web server. These projects are not aimed at production use; they are aimed at understanding. The alumni who describe their most transformative learning experiences disproportionately mention these from-scratch projects precisely because they eliminate the abstraction layers that make tools easy to use but opaque about their inner workings.

Project Category: Data Analysis on Something You Care About

Choosing a topic that generates genuine curiosity -- sports statistics, music trends, neighborhood changes, environmental data, personal health metrics, financial market patterns -- and answering a specific question about it using data develops skills with exceptional transferability.

The data analysis project teaches data cleaning (the majority of any real data project), statistical reasoning, visualization design, and analytical communication. Unlike domain-specific technical skills, these capabilities transfer across fields: a data analyst who has worked with sports data, public health data, and financial data has developed portable skills that apply to whatever domain their career leads them toward.

The genuine curiosity constraint is not incidental. Data analysis projects fail most often not because the technical challenge is too great but because interest in the question fades when the work becomes tedious, which it always does at the data cleaning stage. A project motivated by genuine curiosity sustains through the tedious stages in a way that a project on a chosen-for-technical-reasons dataset does not.

The analytical discipline developed in personal data projects also develops honest thinking habits. When you are analyzing data about something you care about, the temptation to interpret ambiguous results in a flattering direction is real and immediate. Resisting this temptation -- following the data rather than the preferred conclusion -- is a skill that develops through practice, and personal data projects provide the highest-stakes practice because the results actually matter to the analyst.

For a more structured approach to data analysis projects with increasing complexity, see data analysis project ideas, which provides project structures from beginner descriptive analysis through advanced predictive modeling.

Scoping for Completion: The Most Important Design Decision

The largest graveyard in side project culture is abandoned projects. The leading cause of abandonment is not technical difficulty, fading motivation, or competing priorities -- it is scope that expanded beyond what the builder could complete in available time, producing the discouraging experience of working for weeks without ever finishing anything.

The antidote is aggressive, almost embarrassing scope reduction. Take your initial vision, identify the single most essential piece of it, and build only that. A task management app for the first week should handle exactly one thing: creating and completing text tasks. No categories, no due dates, no priorities, no tags, no collaboration. One thing. Working.

"Shipping is a feature. A really important feature. Your product must have it." -- Joel Spolsky

The insight behind Spolsky's formulation is that a finished minimal thing teaches more than an abandoned ambitious thing in almost every dimension. The minimal thing reveals whether your interest in the domain is genuine (do you want to extend it?) and what actually matters in practice versus what seemed important in the abstract. The abandoned ambitious thing teaches nothing about the domain and something discouraging about your own capability that is not accurate.

Time-boxing as scope control. Setting a hard deadline -- two weeks is ideal for most learning projects -- and committing to ship whatever exists at that deadline forces prioritization decisions that are themselves valuable learning. In professional settings, you almost never have enough time to build everything you want; the discipline of deciding what matters most and delivering within a constraint is a skill that side projects can develop directly.

Time-boxing also reveals what you actually value in a project. Given two weeks, what do you spend the first day building? The first week? The last day before the deadline? The pattern of your actual time allocation under constraints, versus your imagined allocation in the abstract, is diagnostic information about your genuine priorities.

Getting Feedback as a Learning Accelerator

Side projects without feedback loops produce learning, but they produce it more slowly and less reliably than projects with external validation and correction. The builder's own assessment of whether something works is necessarily limited by the blindspots that motivated the initial design decisions. External perspectives -- from users, from peers, from communities -- surface problems and opportunities that self-assessment cannot.

Sharing in relevant communities. Posting your project on Hacker News, Reddit, domain-specific forums, or Discord communities generates feedback that varies in quality but often includes specific, actionable critique. The most valuable feedback comes from people who would actually use the thing -- which means posting in communities where the target user congregates rather than communities focused on the technology you used to build it.

The key to useful community feedback is asking specific questions rather than seeking general evaluation. "How could I improve the data model for this feature?" produces more useful responses than "What do you think?" The specific question signals that you are genuinely seeking technical critique rather than validation, and it gives respondents a focused problem to engage with.

Writing about what you built. Writing a post-project retrospective -- what you built, the key decisions you made, the problems you encountered, what you would do differently -- forces the reflective processing that solidifies learning. You cannot write clearly about something you do not understand clearly, so the writing process surfaces gaps and misconceptions that the building process obscured.

Published write-ups also function as portfolio pieces that demonstrate both technical capability and communication skill. The interviewer who reads a thoughtful retrospective about a project learns more about the candidate's thinking than any resume entry could convey, because the retrospective shows the reasoning behind decisions rather than just the fact of their completion.

Having someone actually use your project. If the project has even one real user beyond yourself, their experience surfaces usability problems, missing functionality, and incorrect assumptions that builders cannot see from the inside. The gap between how you imagine people will use something and how they actually use it is reliably large; direct observation or user feedback is the only way to close it.

Building in Public: Accountability and Communication Practice

The practice of publicly documenting a building process -- through blog posts, social media updates, or video logs -- adds accountability and communication development to the technical learning of the project.

Building in public functions primarily as an accountability mechanism. The commitment to weekly updates creates the same motivational effect as an external deadline: the social contract with an audience makes it harder to quietly abandon the project when progress stalls. This is not primarily about building an audience (which requires sustained consistency over months) but about using the public commitment as a forcing function during the project.

The communication skill developed through building in public is distinct from and complementary to the technical skill developed through building. Explaining what you are building, why you made specific design decisions, and what problems you are encountering develops the ability to translate technical complexity into accessible narrative. This skill is independently valuable and increasingly demanded in technical roles that require cross-functional collaboration.

The risk of building in public is performative distortion: optimizing decisions for what would make a good update rather than what the project needs. If you find yourself spending more time on the narrative of the project than on the project itself, or choosing technical approaches because they are interesting to write about rather than because they are appropriate solutions, the public accountability is actively harming the project.

The Transferable Skills That Side Projects Develop

The specific technologies learned in any particular side project will eventually become outdated. The transferable skills developed through the project of building -- across technologies, project types, and domains -- compound indefinitely.

Problem decomposition. Every side project begins as an ambiguous goal and must be broken into specific, actionable steps with clear dependencies and reasonable sequencing. This skill -- transforming an unclear large objective into a concrete plan -- applies to every professional domain and does not become obsolete.

Learning to learn. Each side project requires picking up unfamiliar tools, techniques, and concepts. The meta-skill of learning new things efficiently -- knowing how to use documentation, how to read error messages, how to search effectively for solutions, when to persist through confusion versus when to seek outside help -- compounds across every future learning challenge. The tenth unfamiliar technology is easier to learn than the first not because the technologies are simpler but because the learner has developed better strategies for navigating unfamiliarity.

Shipping. The discipline of finishing something and putting it into the world -- despite imperfections, despite the urge to add one more feature, despite the uncomfortable exposure of letting others see your work -- is a skill that distinguishes productive professionals from those who perpetually refine but never complete. Side projects are one of the few contexts in which this discipline can be developed independently, without the organizational forcing functions of professional deadlines and team accountability.

Honest self-assessment. Building something that must work in the real world produces immediate, honest feedback that most professional contexts moderate or delay. When your code does not work, it does not work -- there is no partial credit, no organizational politics, no grade on a curve. This honest feedback environment, uncomfortable as it sometimes is, develops the accurate self-assessment that allows effective growth.

For the specific skill development context that makes side projects most valuable for career positioning, see low-risk learning projects, which covers how to sequence side project learning within a broader career development strategy.

When Side Projects Become Something More

Some side projects remain private learning experiments forever, and this is fine. Others grow into public portfolio pieces, open-source contributions, business products, or career transitions. The project's trajectory should be driven by what you discover through building it, not by the aspirations you had before building anything.

The questions that guide next-step decisions after a side project:

  • Do you find yourself wanting to work on this even when you are not supposed to be?
  • Do other people who use it find it valuable enough to tell other people about it?
  • Does the domain you built in pull you toward learning more, or has the curiosity been satisfied?
  • Has the project revealed skills you want to develop further or problems you want to solve better?

Positive answers to these questions are evidence for deeper commitment. Negative answers are not failures; they are accurate information about where your genuine interests and aptitudes lie -- information that private side project exploration produces with far less cost than public professional pivots.

References

Tags

side projects skill development learning project ideas portfolio

Frequently Asked Questions

What makes a side project effective for learning vs. just keeping busy?

Clear learning goal, just beyond current skill level (stretch not overwhelming), produces something you can show/use, involves multiple iterations, includes feedback mechanism, and forces you to solve unfamiliar problems. Busy work feels productive but doesn't build skills.

Should side projects be completely original or can they be re-implementations?

Re-implementing existing tools is excellent for learning—focuses on technique not invention. Original ideas add motivation but aren't required. Best: start with clone to learn fundamentals, then add original features once competent.

How do you scope side projects to actually finish them?

Start absurdly small—reduce scope by 90% from initial idea, define 'done' explicitly upfront, time-box (ship in 1-2 weeks max), cut features ruthlessly, focus on one learning goal not many, and accept 'working' over 'perfect'.

What are high-leverage project ideas for learning programming?

Build: personal automation tools you'll actually use, data analysis on topics you care about, blog/portfolio site from scratch, API wrapper for service you use, browser extension solving your problem, or clone simplified version of app you use daily.

How do you get feedback on side projects to improve learning?

Share on relevant communities (Reddit, Twitter, forums), write explanatory blog post forcing clarity, ask specific questions (not 'thoughts?'), submit to Show HN/product communities, have friend use it, or teach concept to someone else.

Is building in public valuable for learning or just marketing?

Valuable for learning when: forces you to explain decisions (clarifies thinking), accountability accelerates shipping, feedback improves work, and teaches communication. Marketing benefit is bonus. Skip if sharing feels performative vs. genuine documentation.

What project ideas teach transferable skills across domains?

Projects requiring: data analysis and visualization, automation and workflow building, clear communication of complexity, system design thinking, problem decomposition, or user research and iteration. These skills apply widely regardless of specific technology.

Share this article