Code Freezes can have the opposite effect
JensRantil
13 points
3 comments
April 05, 2026
Related Discussions
Found 5 related stories in 57.2ms across 4,562 title embeddings via pgvector HNSW
- Code is run more than read (2023) facundo_olano · 120 pts · April 10, 2026 · 52% similar
- Java is fast, code might not be siegers · 192 pts · March 20, 2026 · 51% similar
- If you thought code writing speed was your problem you have bigger problems mooreds · 306 pts · March 17, 2026 · 48% similar
- Code Is Cheap Now, and That Changes Everything v-mdev · 62 pts · April 09, 2026 · 48% similar
- Codegen is not productivity donutshop · 74 pts · March 15, 2026 · 48% similar
Discussion Highlights (2 comments)
trustfixsec
Lived this many times. the worst part about these freezes is what happens right before the freeze - everyone will rush to push their changes prior to cutoff, which is exactly when you get the sloppiest commits. and then after the freeze lifts you get a flood of piled up changes all at once. Smaller, continuous deploys with a good rollback are way less risky than big batched releases after a freeze.
WolfeReader
I cannot fathom why anyone would use a code freeze. Just create a branch at the commit you want to "freeze" and let dev teams keep working with their regular branches.