The morning kicked off with a familiar question in our team: why do we always manage to solve things so fast? Why does it feel like we’re constantly racing against the clock—and still delivering solutions that work? In the middle of that discussion, an analogy surfaced that just clicked: we’re wartime programmers.
Not because we ignore best practices. Quite the opposite—we know them well. We know how documentation should be done, how testing should be layered, how sprints are supposed to be perfectly planned out. But we also know when not to apply all of that. Not because it doesn’t matter, but because sometimes the context demands something else: solve, launch, learn, iterate. Ship again and again.
The analogy took us to military doctors and battlefield engineers. Out there, there’s no time for lengthy protocols—you save lives and build infrastructure in days, sometimes hours. Do they follow every best practice? No. Do they prioritize outcomes? Absolutely. And in that environment, that way of working isn’t just valid—it’s necessary.
But then the obvious question came up: is it always better to stick to best practices? The uncomfortable answer: not always. Best practices are especially useful when a team doesn’t yet trust its own operational ability, or when risk has to be spread across many hands. Protocols, permissions, layers of approval, endless analysis—they all add buffers between action and failure, to minimize mistakes and distribute responsibility.
That’s not a bad thing. It’s needed in many kinds of projects. When you’re coordinating huge teams and complex functions, bureaucracy, long timelines, and standardization make sense. If something goes wrong, there’s a whole chain explaining why, who approved what, and who reviewed what. In the end, no single person carries the full weight of responsibility. Risk gets diluted.
Personally, I choose a different path. I’d rather take full ownership of what I do. I enjoy working with small, tight-knit teams that share a high level of understanding and judgment. I like when complexity sits on a few shoulders—but shoulders that accept responsibility. I like building fast, launching fast, learning fast. Solve first, then improve. That’s my philosophy.
This doesn’t mean dismissing other approaches. There are critical systems—healthcare, aviation, finance, infrastructure—where strict processes don’t just make sense, they save lives and prevent disasters. I get that, and I respect it. But I also know there are projects where the “wartime” mindset is what makes all the difference: speed, focus, and delivery.
To ground it, two examples:
- If you send a corporate engineer into a war zone and ask them to set up an operational base, they’ll ask for permits, studies, validations, and timelines that could take years. That just won’t work in the field.
- On the other hand, if you ask a military engineer to construct a building with strict environmental certifications and complex compliance standards, they won’t be the right fit either. Different goals, different pace.
There’s a team for every context. The important thing is knowing which to choose. Some projects need corporate programmers; others need wartime programmers. Pretending otherwise only creates confusion.
As for me, I’m a wartime programmer. I accept the pros and cons. I embrace responsibility and speed. I’d rather learn in production, fix along the way, and keep shipping. Because I believe that in the right context, this way of working brings out the best in people: judgment, courage, craft.
That’s how I’ll keep living this profession—solving, launching, improving. Trusting my team. Trusting that when speed is essential, the right answer isn’t always more process, but more ownership. And to me, that’s the difference between simply building… and truly moving forward.
