For most of our industry's history the hard part was building the thing.
Writing it took time. That constraint quietly did a lot of work for us. If something was expensive to build, somebody had to justify it, and a lot of bad ideas died in that conversation.
That constraint is loosening, fast.
Building is getting cheaper every year. Scaffolding a service, wiring up an integration, producing a first working version of almost anything is no longer the bottleneck it was when you started reading about this job.
Which means the expensive part moves.
It moves to deciding what deserves to exist.
I think this is the skill worth investing in, and almost nobody is teaching it.
Because the failure mode ahead is not teams that cannot build enough. It is teams that build enormous amounts of the wrong thing, very quickly, and then spend years maintaining it.
Every feature you ship is a permanent liability. It has to be tested, documented, migrated, explained to new hires, and eventually removed by someone who is not sure whether it is safe to touch.
Cheap to create has never meant cheap to own.
So practise the other muscle.
Ask what happens if we do not build this. Sit with the answer honestly instead of racing past it.
Ask who specifically asked for it, and whether they asked for the feature or described a problem.
Get comfortable proposing the smaller version, and comfortable being the person in the room who says this one is not worth it.
That takes more nerve than shipping. Shipping looks like productivity. Declining looks like nothing happened, and nothing happened is very hard to put on a performance review.
Do it anyway.
The engineers who matter in the next decade will not be the ones who could produce the most code. That will be roughly everyone.
They will be the ones with good judgment about which code should exist at all.
Learn to build well, absolutely.
Then learn when to put the tools down.
– Asael Shinder
Top comments (0)