There’s one question every developer should ask before they change anything, and almost nobody is taught to ask it.
What’s the worst thing that happens if I’m wrong here?
Search “risks in software development” and you get the same article over and over. A tidy list of project categories. Budget risk, schedule risk, scope creep, technical risk, security risk. It reads like something a project manager keeps in a binder. None of it tells a developer how to do their actual job differently on a Tuesday afternoon when they’re about to push a change.
That checklist misses the risk that decides whether you’re any good. Every change you make carries a blast radius, the amount of damage it can do if it goes wrong. A senior engineer reads that blast radius before they start and lets it set how careful to be. A weaker one treats every line of code the same way, and that’s a problem in both directions. They move too slowly where nothing’s at stake, and they walk straight into the changes that look harmless but aren’t.
This is a guide to reading that blast radius. It’s written as much for our own engineers at Full Scale as it is for anyone else, because this judgment is the thing that separates a developer who moves the business forward from one who just takes tickets.
