필사 모드: Turning a Side Project Into a Career Asset — A Definition of Done, a Ship Date, and a Retro

Introduction — The Dozen Beginnings Left in a Folder

Open your projects folder and the scenery is usually the same. An app that got as far as the login screen, a repository with a beautiful README and nothing else, a branch that has been quiet for eight months behind three initial commits. You started about a dozen; one or two shipped. And the feeling that comes with reading that list is usually self-blame, landing on the conclusion that you lack persistence.

But persistence is mostly the wrong diagnosis. Line the dead projects up and three things they share come out. First, there was no definition of done. Work with no definition of what finished looks like cannot finish. There is always one more feature to think of, and there is always a little more polishing to do. Without a defined end, the only exit left is stopping out of exhaustion.

Second, there was no ship date. Nobody prioritizes work that has no deadline. Work has deadlines and side projects do not, so whenever the two collide, the side that gives is already decided. Third, there was no retrospective. Finished or dead, if you never wrote a single page about what you learned, what is left six months later is neither code nor experience but a blurry memory that you once started that thing.

A bias sits on top of all this: the planning fallacy, named by Daniel Kahneman and Amos Tversky in 1979. In a well-known experiment run by Roger Buehler and colleagues in 1994, students writing their theses predicted they would finish in about 34 days on average, while the actual average was 55 days. When asked to assume the best case, the predictions got shorter and the accuracy got worse. The feeling that you could build the whole thing over a weekend is not information. It is a symptom.

The Three Conditions of a Project That Becomes an Asset

Not every side project has to become a career asset. Doing something purely for fun is complete in itself. But if you want to use it as an asset, three conditions attach.

First, other people have to be able to see it. Something that exists only on your machine is the same as something that does not exist. A deployed URL, a public repository, a store link, or at minimum one post with screenshots attached. The cost of making it visible is about 5 percent of the whole project, and more than half of the asset value comes from there.

Second, your judgment has to be visible. The tenth to-do app built straight from a tutorial contains not one decision of yours. Whereas a single trace like "I judged that we did not need real-time sync so I went with polling, and cut complexity here instead" makes the project read differently on a resume. Judgment has nothing to do with scale. A 300-line tool has trade-offs in it too.

Third, you have to be able to tell it as a story. If you cannot explain the problem, the choice, and the outcome in 90 seconds, it is unusable in an interview and in conversation. And that story does not get invented after the project ends; it comes out of the notes you took while it was running.

Forcing Scope Down — Two Weeks and an Embarrassing v1

Scope does not shrink voluntarily. It has to be forced by structure.

The device that works best is inverting the order. The approach Basecamp laid out in Shape Up is worth borrowing. Normally you decide what you want to build and then estimate a duration to match; this approach nails down the time you are willing to spend first, and shaves features until they fit inside it. For a side project, whatever you can ship within two weeks is a good default. Two weeks is close to the maximum span over which enthusiasm survives, and close to the minimum that can survive one heavy week at work.

Fitting into two weeks makes what to cut obvious. Sign-up and authentication (for now you are the only user), an admin screen (you look at the database directly), a settings page (constants in the code), responsive design (v1 is desktop only), localization. Writing that list in advance turns cutting from a defeat into the execution of a plan.

Embarrassment deserves a word too. Reid Hoffman, who founded LinkedIn, said that if you are not embarrassed by the first version of your product, you launched too late. This is not an instruction to abandon quality. It is closer to saying make the judgment about completeness outside your room rather than inside it. Two weeks of polishing alone and two weeks after showing it to three users run in completely different directions.

The advice has limits, though. In areas where the cost of an early mistake is asymmetrically large, such as payments, medicine, or security, you cannot apply it as written. An embarrassing v1 is permitted in the territory of reversible decisions.

Why One Small Finished Thing Beats Five Big Unfinished Ones

One small finished thing on a resume is stronger than five unfinished projects. Not because of virtues like humility or honesty, but because of the nature of the questions that actually get asked in interviews.

Questions about a project almost always circle these four. Why did you build this? Why did you decide this part this way? What turned out different from what you expected? What would you change if you did it again? All four can only be answered by someone who went all the way to the end. An unfinished project has no deployment, so it has no moment that defied expectations and no result to look back at. All that is left is intent, and intent cannot be verified.

The third question in particular is the fork in the road. Someone who actually shipped has material to spare. The response that was 100 milliseconds locally and 3 seconds in the real environment. The feature nobody was supposed to use turning out to be the only one used. The first outage where you could see nothing because you had never added error logs. One story like that builds more trust than a description of a perfectly designed, unfinished architecture.

A misconception about scale is worth clearing up. What impresses an interviewer is not the size of the project but the density of the decisions. One real problem you hit while building a tool that 40 people use carries a conversation much further than six microservices nobody uses. How to move a project from this angle into resume sentences is covered more concretely in the resume that gets read.

More Leverage Than Code — Writing and Speaking

You can put the same four hours into code or into writing. Surprisingly often, from a career perspective, the second has the higher return.

The reason is simple. Code has to be visited to be read, whereas writing gets found by search and spreads by link. A repository is raw material that a visitor has to evaluate for themselves; a post that says "here is how I solved this problem, and here is what failed" delivers the evaluation along with it. What becomes an asset is not the artifact but the interpretation attached to the artifact.

There is evidence on the learning-efficiency side too. In an experiment published by John Nestojko and colleagues in 2014, participants told they would later have to teach the material to someone else remembered it better than participants told they would be tested on it. Expecting to teach changes the very way you organize information. Writing things up as you build is not a side job stealing your time; it is part of the learning.

In practice three formats have the best cost-to-effect ratio. First, one project retrospective post — problem, choice, failure, what I would do again. Second, one narrow technical post that broke off from the project, something like "here is how I handled WebSocket reconnection." Search traffic mostly comes from there. Third, an internal talk or a small meetup, fifteen minutes. What a talk leaves behind is the preparation rather than the audience size, and the slides become the skeleton of the next post as they are.

And these three feed each other. The talk becomes a post, the post brings readers to the next project, and a reader question becomes the next project's subject. The point where a side project starts compounding is not in the code but in this loop.

The Boundary With Your Employer — Read the Contract First

This part is not the fun part, but it has to be checked. To be clear up front, what follows is practical caution, not legal advice. If there is any real prospect of a dispute, please get advice from a professional.

The issues usually split along three axes. Did you build it during working hours, did you use company equipment or resources, and is the content connected to company business? Article 9 of the Korean Copyright Act provides that where a work is created in the course of duties under the planning of a legal entity and published under that entity's name, the author is in principle the entity. On the patent side there is the concept of an employee invention under the Korean Invention Promotion Act, where an invention that falls within the scope of the company's business and within the employee's duties gives the company certain recognized rights. The further you are from all three axes the safer you are, and the closer you get, the wider the gray zone becomes.

The most common mistake comes from the contract rather than from the statute. Employment agreements and the separate undertakings people sign on joining often contain clauses on intellectual property assignment, moonlighting, and non-competition, and the scope written into those clauses is sometimes broader than what the law prescribes. Checking right now what it was that you signed without reading when you joined is the only action item in this section. If you do not have a copy, ask HR for one. Asking is not a strange thing to do at all.

The practical safeguards are simple. Work only on a personal laptop and personal accounts. Do not let your commit times cluster inside working hours. Do not move a single line of company code or internal data. If the thing competes with or substitutes for a company product, ask before you start. And when in doubt, getting a short confirmation by email is the cheapest insurance available. Verbal approval disappears when the person giving it changes.

Once monetization enters the picture, the bar rises another notch. A company that raised no objection while it was free and open source sometimes changes posture when it becomes a paid product. Separate internal rules on outside work may apply. The moment you start taking money is the moment to check again.

A Sustainable Rhythm — Four Hours a Week

The last part is about persistence rather than speed.

I recommend four hours a week. It looks small, but it is 200 hours a year, and plenty for running through several two-week projects to the end. Above all, this much survives the weeks with late nights at the office and the weeks you spend with a cold. What kills a side project is not laziness but the backlash that arrives after three weeks of pouring in 15 hours a week. A sprint moves the progress bar but breaks the rhythm, and a broken rhythm takes months to recover.

How you spend the four hours matters too. Two two-hour blocks beat eight thirty-minute ones by a wide margin. Coding takes 20 minutes just to rebuild context, so short fragments get consumed almost entirely by the warm-up. Fixing the day and the time helps as well, because it removes the decision cost of choosing when each time. The principle of designing a system rather than a goal is exactly what systems over goals covers.

And put the rest intervals into the plan in advance. After shipping one project, start nothing for two weeks. The gap feels like laziness, but the time to write the retro and pick the next subject only comes from there. People who create a new repository the day after shipping usually stop at their third project.

Finally, if a period arrives when you do not want to do anything, it may not be a project problem. A side project runs on energy you have left over, not on energy you squeeze out of an empty tank. If work alone already puts you in deficit, what that period needs is recovery rather than a new repository.

Closing — One Link, Two Weeks From Now

You do not have to resurrect the unfinished projects sitting in your folder. Pick one of them, and today there is only this to do. Write the definition of v1 in three lines, put the ship date in your calendar, and make the list of features you will cut. What remains two weeks later is not a perfect product but one link and a one-page retro.

That one link makes the readers for your next project, the material for your next conversation, and the first five minutes of your next interview. Compounding does not begin with a big return. It begins with one small thing you took all the way.