The Art of Not Breaking Things: A CbC Manifesto… a mindset to build polished code
Writing code is a lot similar to carpentry..If you eyeball the cut, saw like a maniac with confusion in mind, and then later try to fix the gap with glue, you aren’t building a table, you are building a hazard.
Correctness by Construction (CbC) is the shift from the chaotic energy of “Let’s see if this runs” to the calm confidence of “I know this runs because I made it impossible for it not to.”
p.s. “No, not Complete blood Count (CbC) :3”
Let me talk about potential tradeoffs before jumping into how we could achieve the CbC mindset,
Pros
- Peace: You spend 90% less time in the debugger (which is just a crime scene where you are both the detective and the murderer).
- Sleep: Yeah.
Cons
- Slower Start: You have to think before you type. It feels less like “hacking” and more like “engineering.”
- Boredom: You won’t look as busy to your peers because you aren’t “putting out fires” constantly.
Here is the toolkit for your CbC journey, a guide to replacing ‘hope’ with the certainty of flawless, intentional design.
The Prologue: Strong Specifications

Before you write a single line of code, write the story. Define exactly what the function does,
- The Vibe: Don’t build a house based on a napkin sketch.
- The Habit: If you can’t explain the constraints in English, you certainly can’t explain them in JavaScript ;)
The Bouncer: Safe Languages & Types

Use your type system to forbid “impossible” situations. A bug cannot happen if the code literally refuses to compile it.
Don’t: Build a “Frankenstein” object full of optional flags
- Bad: A request state like
{ isLoading: boolean, error?: string, data?: string }.
- The Trap: You can accidentally create a state where isLoading: true and error: “Failed”. Is it loading? Is it broken? The code is confused, and so are you.
Do: Use Discriminated Unions. Force the data to exist only when the state allows it.
- Good: Define distinct states
type State = { status: "loading" } | { status: "success"; data: string };
If you check status === ‘loading’, TypeScript physically prevents you from accessing .data. It doesn’t exist yet. The compiler catches the bug before you even run the code.
The Handshake: Design-by-Contract

Every function is a business deal.
- Preconditions: “You promise to give me a positive number.”
- Postconditions: “I promise to return its square root.”
- Invariants: “I promise the database never catches fire.” If the contract is broken, the program shouldn’t try to limp along, it should shout immediately!
The Haiku: Modularity & Simplicity

Complexity is where bugs hide to reproduce. Keep your components small, pure, and simple.
- The Philosophy: Write code like a Haiku, not a dissertation. If a function does three things, it’s doing two things too many.
Code Hygiene: Avoid Error-Prone Patterns

Some patterns are just slippery floors waiting for a lawsuit.
- Don’t: Use shared mutable state (global variables that everyone touches). That’s like sharing a toothbrush.
- Do: Use Pure Functions (same input always equals same output) and Result types instead of throwing random Exceptions.
The Epilogue: Tests Confirm, They Don’t Fix

Testing is your safety net, not your construction plan.
- The Shift: If you rely on tests to find all your bugs, you’ve already lost.
- The Goal: Build it so solid that the tests are just a formality, a victory lap to prove you were right all along.
The Grand Finale
Adopt the mindset of a sculptor. You don’t chip away stone and hope it looks like a horse later. You verify every angle as you go.