2 minute read

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

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

The Bouncer

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

The Handshake

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

The Haiku

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

Code Hygiene

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

Tests Confirm

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.