CohortX
Блог

Showing unfinished work without dread

5 августа 2026 г. · 3 мин чтения · Читать по-русски · Антон Молотило

Why you can't wait until it's ready

Three reasons, each expensive:

A flaw in the concept surfaces late. A month of work, then it turns out something else was needed. Shown on day three, you'd have lost three days.

Readiness never arrives. There's always more to do. The bar rises as you approach it, and "I'll show it when it's decent" becomes "I never showed it".

The fear grows over time. The longer you don't show, the scarier it gets: you've invested a lot and criticism lands harder.

About the fear of showing

Everyone has it, including experienced people. The root is usually the same: it feels as though what's being judged isn't the work but you.

What helps in practice:

Name the state out loud. "This is a draft, the interface is ugly, I only care about the logic." That sets the frame and the conversation stays on substance rather than styling.

Ask something specific. Not "what do you think?" but "is it clear what's happening here?" or "did I understand the problem correctly?". A general question gets a general answer.

Remember the scale. Three people will look at your draft for two minutes. The significance of the event is usually vastly overestimated.

When to show

As soon as something works. Even if it's ugly. One screen, one button, but working.

After every noticeable piece. Don't hoard for a week.

Definitely before it's finished. Showing a finished thing is too late: changing it feels wasteful and feedback reads as complaint.

Who to show

The team. Constantly and without ceremony.

The people you're building for. The most valuable feedback and the most frightening. Three people from your future audience will tell you more than thirty colleagues.

Someone more experienced. On a specific question, not "review my whole project".

Taking criticism

Listen to all of it first. Don't interrupt to explain why it's like that. Understand first, respond after.

Separate fact from opinion. "The button doesn't work on a phone" is a fact you can check. "I don't like the colour" is an opinion you may or may not act on.

Ask about the cause. "What exactly made it difficult?" People describe what got in their way well and propose solutions badly. Take the former; design the solution yourself.

Don't agree with everything. Acting on every comment is impossible — they contradict each other. Deciding what matters is your job.

Don't argue with someone describing their experience. If they didn't understand how to use it, they aren't mistaken; they genuinely didn't understand. Arguing is pointless.

What not to do

Don't apologise in advance. A long preamble about how bad and unfinished it is damages the impression more than the work does.

Don't show without a question. "Here, look" with no indication of what you want spoils the feedback into remarks about button colours.

Don't show only to friends. They'll say "great". Pleasant and useless.

A side effect

The habit of regularly showing unfinished work is exactly what employment demands: demonstrations, code review, discussing decisions. Someone used to it feels noticeably calmer in a team.

Whereas someone who spent a year building alone and showing nobody experiences all of it at once at their first demo — everything they could have absorbed gradually.

Хватит читать — пора делать

На CohortX можно найти команду под пет-проект и получить тот самый опыт, о котором спрашивают на собеседовании.

Похожие статьи