Someone new joins on Monday.
By Thursday
they still cannot run the thing.
Not because they are slow.
Because the README
was true in March,
and it is September now.
We treat setup
as the hallway
before the real house.
Nobody decorates a hallway.
So the hallway grows
a missing environment variable,
a service you have to start by hand,
a version of the runtime
that only one laptop remembers.
And every new person
walks it again,
alone,
in the dark,
asking a question
in a channel
where the answer scrolled away
two years ago.
Here is the reframe.
The setup is the product.
Not for the customer.
For the people
who will build the product.
If it takes three days
to reach the first green test,
you pay that
every hire,
every new machine,
every time someone comes back
and the world has moved.
So write the script.
One command.
Fresh machine.
No tribal knowledge.
If it needs a secret,
say which one and where.
If it needs a service,
start it.
If it will fail,
fail with a sentence
that tells a human
what to do next.
Then do the honest test.
Not on your laptop,
which has been quietly patched
by two years of you.
On a machine
that has never met your project.
That is the only run
that proves anything.
And keep it alive.
A setup script is a test
that nobody wrote a test for.
Run it weekly,
in an empty container,
so it breaks in front of you
instead of in front of
the newest person here.
Half the pain in a codebase
is not in the codebase.
It is in the gap
between cloning it
and running it.
Close that gap
and everything downstream
gets cheaper.
The review is faster,
because the reviewer
can actually run the branch.
The fix is smaller,
because reproducing the bug
took a minute
instead of an afternoon.
And someone finally tries
the risky idea,
because trying
stopped being expensive.
Nobody ever wrote
"made the setup boring"
in a performance review.
They should.
It is the one change
that makes every other change
possible.
– Serguey Asael Shinder
Top comments (0)