Chaos and Order

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

What a Portfolio Actually Does
What Works and What Does Not
The Return and the Limits of Writing in Public
The Reality of Open Source Contribution
The Constraint of a Time Budget
One Thing You Can Do Today
Where This Advice Does Not Apply
Further Reading

What a Portfolio Actually Does

The weakness of work done inside a company is that it cannot be verified. Most of it is private, it belongs to a team so your share is hard to separate out, and in the end it travels only through your own account of it. Work outside is different: one link and the other person confirms it directly.

But it is a complement, not a substitute. Outside work rarely stands in for a career inside, and it usually does two jobs instead. First, it attaches verifiable grounds to one of the claims on your résumé. Second, it creates accidental contact. Internal achievements are not searchable; published things are.

That makes the test simple. Does this make one of my claims verifiable? If not, it can still be something you do for pleasure, but it is not a portfolio. Mixing the two tends to produce less pleasure and no evidence.

What Works and What Does Not

Start with what does not. Something built by following a tutorial, a repository that was started and stopped, a page with a profile and no output, and sheer count. Ten unfinished things are weaker than one finished one, because what the reader is checking is not the ceiling of your ability but whether you go all the way to the end.

What works looks like this.

A small finished thing. Narrow in scope, actually running, and usable by someone else.
A document that states the problem. What you built and why, where you got stuck, what you gave up. This document gets read more than the code does.
Traces of other people using it. Issues, questions, forks. Even a handful of users is itself evidence of completeness.
Something connected to your direction. It is worth the most when it belongs to the same class of problem you want to work on next.

The Return and the Limits of Writing in Public

There are three returns. First, the act of writing exposes the holes in your own understanding — a return that arrives even if nobody reads it. Second, it becomes a searchable index; later someone finds you by the problem rather than by your name. Third, accidental connections happen.

The limits are just as clear. Most writing is not read. The reward does not arrive immediately, accumulation takes time, and how much time is not knowable in advance. So aiming at a response usually means quitting within a few months. Aim instead at a reference for yourself and the first piece has already paid for itself, with readers as a bonus.

One more thing. When you write about work, what you may publish differs by contract and by jurisdiction. How far you can go with internal or customer information is something each person has to check, and when it is ambiguous it is safer to ask before publishing.

The Reality of Open Source Contribution

The first way in is usually not code. Fixing documentation, reproducing an issue, adding a test, reading someone else's change and leaving one precise question — those are the realistic starts. Beginning with a large feature proposal usually does not get merged, because each project has already settled the range of what it accepts.

Three things are worth knowing before you begin. There may be no response, the time to a first merge varies enormously between projects, and there is emotional cost. Maintainers are mostly carving out their own hours, so a slow answer is not personal. And being turned down in public feels different from an internal review — knowing that in advance makes it shake you less.

What actually carries weight on a résumé is not the name of a famous project but the trace of collaboration: the record of taking a review and revising, the question you left after reading someone's code, the explanation you added to the docs. Which is why staying with one project for a long time is stronger than passing through many once each.

The Constraint of a Time Budget

Hours outside work are not unlimited, and they draw from the same account as rest, health, and relationships. Leave that calculation out and the situation where a portfolio erodes a career genuinely occurs. Nights spent make daytime judgment worse, and once daytime results slip, the loss outweighs what outside evidence can recover.

So it is better to fix two things before starting: how many hours a week this gets, and what you would have to see in order to stop. Without an exit condition no project ends, and what does not end does not become evidence.

One Thing You Can Do Today

Do not start something new. Today's task is to pick one of the things you already half-built, write its definition of done in one line, and attach a publication date. Set the bar low. Install instructions plus one example, and a first-time reader can run it within a few minutes — that is enough (this is a constructed example). Deleting most of the scope you originally planned is usually the right call. What you delete leaves nothing behind, but what finishes does.

Where This Advice Does Not Apply

The scope of outside activity and intellectual property differs by employment contract and by jurisdiction. What you may publish varies by company and by country, so check your own contract rather than trusting a general claim. This is a matter of fact-checking, not of caution.

Some people structurally have no free hours: caregiving, health that leaves no slack, a second job. A standard that demands outside evidence is not fair to them, and forcing yourself to meet it at the cost of your body is worse than not meeting it. In that case, building verifiable evidence inside the company is the realistic route: a design document that can be shared, an internal talk, material written for new joiners.

Finally, there is the case where internal evidence is already sufficient. The further a career goes, the more the weight of verification shifts from artifacts to testimony from people. In that stretch, having five people who worked with you able to describe you accurately is stronger than one more repository.