What Plastering Taught Me About Building Software

Nikos Katsikanis - April 10, 2026

Last week I plastered my first wall and made the classic mistake of doing it in halves. I finished the bottom section first, then moved up and did the top. The join between them turned messy because the wall should have been done in one continuous pass.

That mistake taught me something I have seen in software for years: later polish does not repair earlier disorder.

Instead of one clean finish, I created a bad join and spent the next two days fixing it. I went back over rough areas with jointing compound, sanded down what I had just put on, and tried to recover control after the next layer was already involved. It was a direct lesson in how quickly rework gets expensive once a mistake has been built into the surface.

It felt familiar because software fails in the same way.

A feature can look nearly done. The screens work, the forms submit, the demo holds together. But underneath, the work may have been split or sequenced badly. The visible layer looks finished while the real issues are still there: mixed-up concepts in the model, environment drift, bad assumptions in the data, or logic that only works because nobody has hit the awkward cases yet.

From a distance, fixing that can look like backtracking. Usually it is the first honest pass.

Edges and joins tell the truth first

The flat middle of a wall can look fine for a while. The joins, edges, corners, and transitions are where poor technique shows up first.

Software behaves the same way. Problems appear where one thing meets another: old code and new code, frontend and backend, one service and the next, or a product promise meeting the actual workflow. The middle can look fine for longer than it should. The edges tell the truth first.

Software lets weak foundations hide longer

A wall tells you quickly when the mix is off, the pressure is uneven, or the timing is bad. Software is more forgiving at first. Tests can stay green, demos can still work, and the system can still be setting up future pain.

That delay is part of the danger. Trades push back early. Software often waits until integration, release, or live use. That makes it easier to pretend weak foundations are good enough.

Maintenance is part of the job

Plastering also made it obvious that maintenance is not separate from the work. Clean buckets, clean water, and properly washed tools affect the result directly. If the bucket is dirty, the mix is worse. If the water is filthy, the tools drag more mess back onto the wall.

Software has the same pattern. Dirty working habits carry old mistakes into new work. Stale branches, half-removed config, messy repos, unreliable local environments, and quick fixes left lying around all contaminate the next pass.

More work is not always better work

Extra passes are not always helpful. A lot of plastering comes down to timing, pressure, angle, and knowing when to leave the surface alone. Keep touching it at the wrong moment and you make it worse.

Software has the same trap. I can keep refactoring code that already had the right shape, add structure too early, or keep polishing after the useful gain is gone. Bad timing is not just about rushing. It is also about failing to stop.

What I am taking back into software

Plastering made something visible that software often lets people ignore for too long: the finish cannot rescue a bad layer underneath.

Both jobs reward respecting the stage you are actually in. Prep matters. Sequencing matters. Cleanup matters. Weak joins always come back. Dirty tools carry old mistakes forward.

A good result looks calm at the end, but that calm does not come from magic. It comes from getting the order right, keeping things clean, and doing the right work at the right moment.