💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

Opening — Two People on a Friday Night

There were two colleagues at the same company. For convenience, let us call them A and B. They joined around the same time, earned similar salaries, and shared a similar curiosity about technology trends.

On Friday nights, the two did similar things. They read articles about new tools, watched conference talks, and added trending open-source repositories to their stars. There was just one difference. By Saturday afternoon, B would actually install one of them, break it, and build some small thing with it. A would read the next article.

Two years passed. A still knew the hot new things better than anyone. In conversation, A was knowledgeable. But in that same span, B had built three internal tools, one of which became the team standard, and a tiny weekend side project that gathered thousands of monthly users. The promotions and the job offers went to B.

This essay is not here to criticize A. Most of us live closer to A, and I myself was A for a long time. This is a story about the small difference that separated A and B — **the difference between someone who reads and someone who makes** — and why that difference grows far wider than you would expect, and how you might take one step toward the maker side.

The "builder" in this essay does not mean a grand founder or a genius engineer. It means anyone who makes something all the way through and puts it out into the world. It could be code, writing, a small tool, or a club event. The point is not your job title but your attitude.

Consumer vs. Producer — Same Hours, Different Compounding

We live in a golden age of content. Free courses, newsletters, videos, and Twitter threads flow endlessly. The problem is that this abundance carries a subtle trap. Consumption gives instant satisfaction. You feel "oh, I learned that." But that feeling often fails to match real ability.

The biggest difference between producing and consuming is the **direction of compounding**.

| Aspect | Consumer mode | Producer mode |

| --- | --- | --- |

| Weekend output | Knowledge in your head (volatile) | A real artifact (saved) |

| Feedback | Almost none | Reactions from users and reality |

| Skill curve | Flat, prone to plateaus | Steep, grows when you get stuck |

| Portfolio | Does not accumulate | Accumulates automatically |

| Luck surface area | Narrow | Wide |

| One year later | A similar place | A completely different place |

The phrase "luck surface area" in the last row is the key. When you put what you made into the world, opportunities arrive from directions you never predicted. Someone uses your tool and offers you a job; someone reads your writing and proposes a collaboration. If you only consume, that surface area stays close to zero, because no one can know what you know.

Do not misunderstand. Consumption is not bad. There is no good output without good input. The problem is the **ratio**. Input with no output is not learning; it is collecting.

Consumer mode: read -> read -> read -> read -> (a year later) about the same

Producer mode: read -> make -> get stuck -> read to solve -> make -> (a year later) a different person

Knowledge you sought out because you got stuck while making is different in quality from knowledge you merely read. Knowledge that entered through need sticks because it comes with context. This is the hidden weapon of producer mode. Producing forces learning, and forced learning lasts.

Execution Over Ideas — "I Thought of That First"

There is a line builders hear most often and that means the least. "I thought of that idea a long time ago too."

Almost every good idea exists in many people's heads at the same time. There were thousands who imagined a ride-hailing app, a delivery app, the exact same SaaS. What made the difference was not the imagining but **the one who made it**.

Expressed crudely as a formula, it looks like this.

Value of an idea ~ 1

Value of execution ~ 1,000

Value = idea x execution

= 1 x 1,000 = 1,000 (an ordinary idea, executed)

= 10 x 0 = 0 (a genius idea, not executed)

A genius idea multiplied by zero is zero. Even an ordinary idea, once multiplied by execution, becomes a meaningful number. That is why builders do not hide their ideas as secrets. They actually talk about them freely. The value is created in the making anyway.

There is a psychological trap here too. We often defer endlessly to refine an idea further. "Let me design it just a bit more perfectly before I start." But a design polished on your desk turns out half wrong the moment it meets reality. Execution is the most efficient way to discover that wrong half quickly.

> The builder's way is not to plan perfectly and then execute, but to execute while correcting the plan along the way.

Start Small and Ship — The Power of an Embarrassing v1

The first skill a builder learns is "how to cut scope." The picture in your head is always enormous. Trying to make that enormous picture all at once is how most projects die before they even start.

Reid Hoffman, the founder of LinkedIn, has a famous line. "If you are not embarrassed by the first version of your product, you have launched too late." The point is not to make something sloppy. It means **you cannot know what matters until you receive feedback from reality, so collide with reality as fast as possible.**

The practical principles of starting small are these.

- Make the first version do "one thing" well. If you wrote a feature list, delete 80 percent of it.

- Brutally separate "nice to have" from "cannot live without."

- Set the launch bar not at "perfect" but at "can one real user use it."

- Set an artificially short deadline. Within the weekend, or within two weeks.

For example, suppose you want to build "a system that automatically organizes, searches, and summarizes all of the team's meeting notes." This is a six-month project, and nine times out of ten it dies. A builder slices it like this.

Grand vision: auto-collect notes + search + summarize + share + notify ...

v (delete 80%)

v1 (weekend): a script that reads markdown files in a folder and prints a one-line summary

v2 (next week): send the summary to a Slack channel automatically

v3 (later): add search

The v1 is embarrassingly small. But once v1 exists, v2 appears; once v2 exists, v3 appears. Without v1, it stays in your head forever. Starting small is not laziness; it is the fastest strategy for making something exist.

Fast Feedback Loops — The Builder's Real Engine

Reduce the essence of building to one sentence and it reads like this. **Make -> ship -> watch the reaction -> fix.** The speed of this cycle determines the speed of a builder's growth.

The reason a faster loop is better is simple. We cannot know in advance what is right. The number of times you test a guess is the amount you learn. Ten small launches teach more than one big launch.

Slow loop (ship once a year)

design ---------- 6 months ---------- launch -- reaction -- it flopped

Fast loop (ship every two weeks)

make - ship - react - fix - ship - react - fix - ship - react ...

|--- learned 12 times in the same 6 months ---|

There are concrete ways to make the feedback loop fast.

- **Automate deployment.** If shipping is a hassle, you ship less often. Make it deploy with one command or one push.

- **Pull in users early.** Show it to one friend, one colleague. One word from a real person beats a hundred deliberations alone.

- **Look at the numbers.** Look at data instead of guessing. How many came in, where they left.

- **Build a structure that is easy to change.** Better to make it fast and fix it often than to spend six months designing it perfectly once.

There is an important balance here. A fast loop does not mean "make something sloppy and toss it out." The key is to cut into the **smallest verifiable unit.** Instead of verifying one big hypothesis in six months, verify twelve small hypotheses every two weeks.

What to Make First — A Simple Prioritization Framework

When you hear "go make something," the next question follows immediately. "So what first?" If ten ideas are floating in your head, which one should you bet next weekend on? You do not need an elaborate scorecard. Three questions are enough.

Question 1. Do I use it myself? (user = me means motivation and feedback are free)

Question 2. Can a v1 ship in a weekend? (if scope is big, it dies before it starts)

Question 3. Will anyone see it once done? (does it expand your luck surface area)

If an idea answers "yes" to all three, stop deliberating and start with that one. A project that is yes on all three is a rare combination where motivation, finishability, and reward are all present at once.

| --- | --- | --- | --- | --- |

| Giant SaaS platform | No | No | Yes | Slice and retry |

| Toy compiler in a new language | No | No | No | Learning only |

The lesson of this table is simple. The most ambitious idea is almost never the best first project. The best first project is a small thing that **finishes fast, that you use, and that others can see.** Save the ambition for your second and third projects.

One more thing: these three questions are not only for side projects. They work just as well when you pick "what to improve next" at work. Is it a friction I hit every day, can I show a first version within a week, will the team notice if I finish it? A builder's sense of priority does not distinguish between the job and the side project.

Ownership — The Opposite of "That Is Not My Job"

The clearest line dividing a builder from a mere executor is ownership. Ownership is not a rank or a title but an attitude. It is the mindset of "I will take responsibility and make this all the way through."

Let us compare the language of someone with ownership and someone without it.

| Situation | Without ownership | With ownership |

| --- | --- | --- |

| Found a bug | "Who made this?" | "I will find the cause and fix it." |

| Spec is vague | "The spec was unclear so I could not do it." | "I assumed this and proceeded; please confirm it is right." |

| Project drifting | "There was no clear direction." | "I drafted a plan and scheduled a meeting." |

| Problem after launch | "QA did not catch it." | "I will add monitoring and prepare a hotfix." |

Do you see the difference? The person with ownership pulls problems toward themselves. The person without it pushes problems outward. The interesting part is that ownership looks like a loss but is actually the fastest path to growth. Only the one who takes responsibility gets to see the whole picture, and only the one who sees the whole picture builds the muscle of decision-making.

There is one caution with ownership. It does not mean carrying everything alone. In fact, real ownership includes "asking for help when you need it." Struggling alone for three days when you are stuck is not ownership but stubbornness. Owning the outcome while cleverly pulling in help during the process is mature ownership.

The Builder in the Age of AI — The Barrier to Making Has Fallen

The biggest change in recent years is that the skill barrier to making something has dropped dramatically. It used to take months of study to turn an idea into a form. Now you describe it in plain language and a draft appears.

The meaning of this change can be summarized in two parts.

First, **the barrier to entry has fallen.** A designer builds a simple app, a marketer writes an automation script, a student ships a service over the weekend. The shelf life of the excuse "but I am not a developer" is running out.

Second, paradoxically, **the builder mindset has become more important.** In an era where tools write the code for you, the differentiator becomes the ability to decide what to make, push it all the way through, and refine it with feedback from reality. AI lowered the cost of "how," but "what and why" still belongs to people.

| Era | What was scarce | What became common |

| --- | --- | --- |

| Past | Technical implementation | Ideas |

| Now | Judgment, taste, completeness | Implementation |

There is a trap here as well. When tools get easy, the "feeling of having made something" comes easily too. You run one demo and feel like you finished. But there is still a vast valley between a demo and a shipped product. The one who crosses that valley is a builder. AI does the first 90 percent fast, but the last 10 percent — where the real value lives — still demands human persistence.

Finishing What You Start — Projects That Die at 90 Percent

Here lies the most brutal point that divides builders from amateurs. Anyone can start. Burning through the first weekend on a cool idea is easy. The hard part is **finishing the last 10 percent that has stopped being fun.**

A project's excitement curve usually looks like this.

fun

| *** <- start: everything is thrilling

| **

| ** <- middle: reality's small problems

| ***** <- last 10%: error handling, docs, polish (boring)

| * <- ship!

+------------------------------> time

The last 10 percent is not glamorous. It is work like handling edge cases, refining error messages, configuring deployment, and writing usage instructions. The shiny idea of a new project keeps tempting you. "Wouldn't that be cooler than this?" And so 90-percent corpses pile up in every folder.

Here are practical tips for becoming someone who finishes.

- **Commit publicly.** Say "I will ship by the end of this month" in front of people. A promise lends you persistence.

- **Define shipping in small units.** Put it out by the bar of "one person could use this," not "it is complete."

- **Just write down new ideas.** Do not start before finishing. The idea list is your reward after you finish.

- **Anticipate the last 10 percent in advance.** Remember that the moment you feel "it is done" is actually about halfway there.

The experience of having finished something is an asset in itself. Someone who has made one thing all the way through is far more likely to finish the next. The muscle of completion grows only through completion.

Side Projects — The Safest Laboratory

It is hard to grow the builder muscle through your day job. At work, failure is expensive, scope is fixed, and it is rare for one person to own something from start to finish. That is why side projects matter. A side project is **a laboratory where failure is safe.**

The real value of a side project lies less in the output and more in the following.

- The experience of owning something from start to finish, alone. An experience you can rarely get at work.

- The freedom to try new technology you cannot use at work, as much as you like.

- Expansion of your luck surface area. You never know where or to whom what you made will reach.

- A sense of "something that is mine" that protects you when your day job stops being fun.

That said, side projects have common failure patterns too.

| Failure pattern | Symptom | Prescription |

| --- | --- | --- |

| Grandiosity | First project is too big | Cut it to weekend size |

| Tool collecting | You only configure, never build | Start now with familiar tools |

| Hiding | Hide it until perfect | Publish early, even if embarrassing |

| Wandering | A new project every week | Forbidden until you finish one |

The best first side project is one that solves "a friction you experience yourself." When you are the user, the feedback loop is instant and motivation does not run dry. "That thing that annoys me every week" is a far better starting point than grand market research.

From Start to Finish — One Lap of a Tiny Side Project

Just saying "start small" does not quite land. So let us follow one very small project exactly as it goes from a head-annoyance to a shipped thing.

Here is the situation. Every Monday morning I was hand-collecting the issues that had closed last week in a git repository and pasting them into a retro note. Ten minutes each time, forty minutes a month, and above all it was boring. A textbook "thing that annoys me every week."

First I brutally cut the scope of v1. No search, no web UI, no settings screen. It just "prints, one line each, the titles of issues closed in the last 7 days." That is all.

v1: the goal is to make it run within 30 minutes

mkdir weekly-recap && cd weekly-recap

gh issue list --state closed --limit 50 --json title,closedAt > issues.json

Then I added a short script that filters by close date and pulls only the titles. With familiar tools, learning nothing new.

from datetime import datetime, timedelta, timezone

cutoff = datetime.now(timezone.utc) - timedelta(days=7)

with open("issues.json") as f:

issues = json.load(f)

for it in issues:

closed = datetime.fromisoformat(it["closedAt"].replace("Z", "+00:00"))

if closed >= cutoff:

print("- " + it["title"])

Saturday night, this ran. It was embarrassingly simple, but it clearly "existed." That was the moment something that had lived only in my head first appeared inside a folder.

I did not stop there; I closed one lap of the loop. I showed it to one colleague, and the first feedback came instantly. "With only titles I cannot tell what is important; it would be nice to have links too." A single line that would never have come from a hundred deliberations alone.

v1 (Saturday night): prints titles of issues closed in the last 7 days

v colleague feedback: "need links too"

v2 (Sunday): prints title + link as markdown, copies to clipboard

v my own feedback: "typing the command every week is a hassle too"

v3 (next weekend): schedule it to run automatically every Monday morning

The point is not the code. It is that one lap ran — **head-annoyance -> embarrassing v1 -> one person's feedback -> next version.** Once you complete this lap, the second project becomes unbelievably light. The heavy one is always the first lap.

What is worth noticing in this example is "the things I did not do." I did not attach a database, did not build a login, did not draw a screen, did not support other git services. All of those were "nice to have," and not one of them entered v1. A builder's restraint shows not in what you put in but in what you leave out. One project finished small carries you farther than ten projects started grand and then stalled.

A Conversation With a Mentor — What a Code Review Taught Me

The builder mindset is hard to learn from prose alone. Often a single short conversation changes more than an entire book. When I was a junior, here is a code-review conversation I had with a senior. (It is a reconstruction from memory.)

Junior: "I cannot ship this feature yet. Five edge cases are still left, and I want to clean up the code a bit more."

Senior: "Of those five, how many will an actual user hit this week?"

Junior: "Um... honestly, one? The rest almost never happen, I think."

Senior: "Then let us block just that one, write 'known limitation' as a comment for the other four, and ship it. Solving problems that do not happen in advance is gambling. The users will tell you which ones actually blow up."

Junior: "Still, the code is embarrassing."

Senior: "Being embarrassed is normal. If you look at this code in six months and are not embarrassed, you have not grown in that time. Your job right now is not perfect code but code someone can use tomorrow."

From this conversation I learned two things. First, that perfectionism is often a mask for fear. Behind "I want to polish it more" there is frequently a hidden "I am afraid of reality's judgment." Second, that a good mentor is not someone who gives answers but someone who **shrinks the scope of the question.** That one question — "how many of the five are real" — got me, stuck, moving again.

> A good code review is not a place to fix code but a place to agree on what does not need fixing.

That day I shipped the feature with four lines of "known limitation" comments. And for a whole month, not one of those four actually became a problem. What I had tried to block was a future that would not happen; what the senior had blocked was a present that would never ship. Ever since, whenever "until it is perfect" tries to leave my mouth, I throw that question at myself. "This problem I am trying to block right now — does it really happen this week?"

Concrete Cases — The Differences Making Made

The abstract talk has run long, so let us look at a few patterns of the difference making actually makes. (These are composites of common types, not specific individuals.)

**Case 1. The developer whose internal tool became the standard.** Unable to keep watching teammates repeat manual work, they made a small script over the weekend. At first only they used it, but once they showed a colleague, everyone started using it, and it eventually became the team's official tool. That person became "the one who made the tool" and was naturally drawn into bigger decisions. It started as a 30-line script.

**Case 2. The person whose blog became a career.** Someone steadily wrote down what they learned. For the first six months, there were almost no visitors. But after a year, those posts began surfacing in search, and a company that read them sent an interview invitation. Writing is unmistakably building too. It is the act of taking what is in your head and leaving it outside.

**Case 3. The weekend project that became a side income.** Someone published a small tool they made to solve a friction of their own, and people who shared the same friction started paying to use it. There was no grand business plan. They simply solved "their own problem" and put it out.

These cases share two things. First, the start was always **small**. Second, it did not stay in their head but **came out into the world**. It was not the grand plan but the small launch that made the difference.

Starter Guide — What to Do Next Weekend

If, after reading this far, "so what do I make?" feels overwhelming, here is a concrete starting line.

**Step 1: Make a friction list (15 minutes)**

Write down five moments this week when you felt "ugh, this is annoying." Repeated manual work, things you always forget, information that is a pain to find. The best projects come from here.

**Step 2: Pick the smallest one (5 minutes)**

Among the five, pick the one that "you could at least imitate within a weekend." Resist the temptation to pick the big one.

**Step 3: Define v1 (10 minutes)**

Reduce that one to a form that "does only one thing." If you wrote down features, delete 80 percent. What remains is v1.

**Step 4: Just make it (the weekend)**

It does not have to be perfect. Start with familiar tools. Defer learning new tools to later. The goal is "something that runs by Saturday night."

**Step 5: Show one person (10 minutes)**

Regardless of polish, show it to one friend or colleague. The moment you close that first feedback loop, you have already crossed from consumer to producer.

Builder starter checklist

[ ] I wrote down 5 frictions from this week

[ ] I picked the smallest 1 of them

[ ] I deleted 80% of the features and defined v1

[ ] I started with familiar tools

[ ] I showed it to one person in an imperfect state

[ ] I only wrote down new ideas and finished this one first

What matters is not the scale but **going around the loop once**. Once you finish a single lap of make -> ship -> get a reaction, however small, the next one becomes much easier. The first lap is the heaviest.

But Wait — Common Objections

Whenever the builder mindset comes up, almost the same objections come back. Rather than ignore them, let us answer each one honestly.

**"I have no time."** The most common and the most sincere objection. The answer is not "make time." Building does not demand two empty weekend days. Thirty minutes a day, two or three times a week, is plenty to go around the loop. The problem is not the total amount of time but whether you spend those thirty minutes on production rather than consumption. One Netflix episode equals one v1.

**"My idea has already been built by someone."** A good sign. That someone built it is proof there is demand. Search, notes, chat apps — almost no category is brand new to the world, yet new products keep succeeding. The difference comes not from the idea but from the details of execution. "It already exists" is not a reason not to start but a reason to think about what to do differently.

**"I would be embarrassed if I make it badly."** Let us admit this honestly. It is embarrassing. But no one remembers your v1 as long as you do. People are busy with their own lives. And the world's judgment of "someone who tries and polishes in public" is far more generous than you expect. The real danger is not embarrassment but disappearing without anyone knowing.

**"I lack the skill, so I will start after I learn more."** The most dangerous objection. The condition "once I am ready" is never met. Skill is not filled up before making but filled in while making. Remember that knowledge sought out because you got stuck lasts the longest. Starting is itself the study plan.

**"My day job alone is overwhelming."** Then it is better to turn the day job itself into an arena for building. A side project is not mandatory. Automating one piece of repeated manual work, organizing a vague spec first, making a small tool no one else makes — all of these are building. The builder mindset is not separate time but an attitude toward the same time.

**"I am not confident I can finish."** An honest fear. That is exactly why the first project should be deliberately, ridiculously small. If you are not confident you can finish, that is a signal the project is too big. Shrink it to "something that runs within 30 minutes" and the reason you cannot finish disappears. The muscle of completion grows not through one giant effort but through repeating small completions. Practicing finishing small is the foundation of the ability to finish big.

There is a thread running through these objections. Most are true, but most are not reasons to refrain from starting. An objection is usually not a real obstacle but the reasonable clothing that the fear of starting wears.

So here is a good question to throw at an objection when it arises. "Is this a real wall that blocks starting, or an excuse that lets me not start?" If it is a real wall, find a detour: shrink the scope, change the tool, shift the time slot. But if it is an excuse, the moment you honestly call it an excuse, it loses its power. A builder does not ignore objections. They simply treat an objection not as a pretext but as one more problem to solve.

Balance — The Builder's Most Common Trap, Burnout

By the time you read this far, the urge to "yes, I must build no matter what!" may surge up. So this essay will close with its most important warning. **Building that is not sustainable is not building; it is depletion.**

Builder culture has a dangerous myth. "Work 100 hours a week, sleep when you are dead, grind every weekend into the work." Such narratives look glamorous but mostly end badly. Burnout is the most common cause of death for builders. The one who burns small and steadily ends up going farther than the one who flares up big once and goes cold.

Building is not a sprint but a marathon. Compounding needs time, and to buy time you have to survive. Here are the principles for a sustainable pace.

- **Small, often.** Four hours every week steadily beats 80 hours crammed into one month. Compounding loves frequency.

- **Set an end.** Setting a deadline like "within the weekend" prevents endless grinding.

- **Rest without guilt.** Rest is not laziness but an investment in the next round.

- **Protect the fun.** When a side project becomes one more obligation, it loses its original meaning. If it stops being fun, pause or change it.

- **Take care of your body.** Sleep, exercise, people. If these collapse, no output means anything.

> The most productive builder is not the one who works the longest, but the one who *keeps* working the longest.

Making and depleting yourself are different things. The real builder mindset is closer to "steady, for a long time" than to "more, faster."

Closing — On Living as a Maker

Let us return to A and B from the beginning. What divided the two was not talent, not time, not luck. It was the small habit of installing something on a Saturday afternoon, breaking it, and making a small thing.

Reduce the core of the builder mindset to one sentence and it reads like this. **Instead of only reading the world, live as someone who adds something to it.** That something need not be grand. A 30-line script, one piece of writing, a single small tool is enough.

This essay, too, is ultimately one output. If you only read it, this is just one more act of consumption. Next weekend, when you make one very small thing all the way through and put it into the world — that is the moment this essay finally means something.

Let me close with one small suggestion. After you close this essay, do not open another tab and read another article. Instead, open a notes app and write down five things that annoyed you this week. Those five minutes are the first step that separates a reader from a maker. You do not need a grand resolution or a perfect plan. All you need is to write one line and, next weekend, to put your hands on the smallest one of them.

Makers change the world. And that "maker" is not some grand figure but possibly you, next weekend. The world does not need more readers. The world is waiting for more people who make things all the way through.

References

- Paul Graham, "How to Do Great Work" — [https://paulgraham.com/greatwork.html](https://paulgraham.com/greatwork.html)

- Paul Graham, "Maker's Schedule, Manager's Schedule" — [https://paulgraham.com/makersschedule.html](https://paulgraham.com/makersschedule.html)

- Reid Hoffman, "If You're Not Embarrassed By the First Version, You've Launched Too Late" — [https://www.linkedin.com/pulse/20130829003652-1213-six-lessons-i-learned-the-hard-way-about-scaling-a-startup/](https://www.linkedin.com/pulse/20130829003652-1213-six-lessons-i-learned-the-hard-way-about-scaling-a-startup/)

- Carol Dweck, "Mindset: The New Psychology of Success" (book) — [https://www.penguinrandomhouse.com/books/44330/mindset-by-carol-s-dweck-phd/](https://www.penguinrandomhouse.com/books/44330/mindset-by-carol-s-dweck-phd/)

- Will Larson, "An Elegant Puzzle" and essays — [https://lethain.com/](https://lethain.com/)

- StaffEng, "Stories of reaching Staff-plus engineering roles" — [https://staffeng.com/](https://staffeng.com/)

- Amy Edmondson on psychological safety — [https://hbr.org/2023/02/what-is-psychological-safety](https://hbr.org/2023/02/what-is-psychological-safety)

- Harvard Business Review, "The Power of Small Wins" — [https://hbr.org/2011/05/the-power-of-small-wins](https://hbr.org/2011/05/the-power-of-small-wins)

- Cal Newport, "Deep Work" (book) — [https://www.calnewport.com/books/deep-work/](https://www.calnewport.com/books/deep-work/)

- Jack Butcher, "Build Once, Sell Twice" / Visualize Value — [https://visualizevalue.com/](https://visualizevalue.com/)