Boring Is a Feature
The case for writing code like a little old lady
Coding like a little old lady means doing things deliberately, with the person who reads it next firmly in mind. It means avoiding fads, choosing boring tools on purpose, and being relentlessly kind to whoever has to read your code six months from now, which is usually you. My rule of thumb: don’t make the Alison of six months from now swear about the Alison of today.
This is not about being slow. It is about being deliberate. Durability is a discipline, not a personality trait.
Just because you are vibe coding does not make these principles less relevant. If anything, it makes them more so. AI can generate code faster than any human, but it cannot tell you whether the result is reliable, observable, or maintainable. That part is still yours.
Label Every Jar
No mystery Tupperware in this codebase. If you open a file and cannot tell what a variable does from its name alone, it is already a problem.
# Before
def calc(x, y):
return x * y * 0.0274
# After
def calculate_monthly_interest(principal, annual_rate):
daily_rate = annual_rate / 365
return principal * daily_rate * 30
The second version does not need a comment. The names do the work. That is the goal.
Wrap It in a Good Quilt
Documentation is not a summary of what the code does. Any decent reader can see what it does. Documentation explains why it does it that way.
def calculate_monthly_interest(principal, annual_rate):
"""
Approximates monthly interest using a 30-day month.
We use 365 days (not 360) to match the loan agreement terms.
See: contracts/loan_terms_v2.pdf, section 4.3
"""
daily_rate = annual_rate / 365
return principal * daily_rate * 30
That note about 365 versus 360 will save someone an hour of confusion. Probably you. At the very least, go back and add comments once the code is stable if you don’t like updating it as you make edits.
Measure Twice, Cut Once
Tests are not something you write after the code works. They are how you know what “works” means before you write a single line.
Start with the behavior you expect. Write the test that confirms it. Then write the code that passes it.
# Write the test first
def test_calculate_monthly_interest():
# 12% annual rate on $1000 for 30 days
result = calculate_monthly_interest(1000, 0.12)
assert abs(result - 9.86) < 0.01
# Then write the function to pass it
def calculate_monthly_interest(principal, annual_rate):
daily_rate = annual_rate / 365
return principal * daily_rate * 30
This sequence forces you to think about the contract before you think about the implementation. It also means that when someone changes the logic six months from now, the tests will tell them immediately what they broke and what it was supposed to do.
Measure twice, cut once. The second measurement is the one that saves you.
Avoid Flimsy Gadgets
Every framework was someone’s exciting new idea once. The question is not whether something is new. It is whether it will still be maintained when you need to patch it at 11pm on a Friday.
Choose tools that have been around long enough to have opinions about. Check the last commit date. Read the issue tracker. If the community is quiet, the library is either perfect or abandoned, and you will not know which until it is your problem.
Boring is a feature.
None of this means stop experimenting. Play with the new thing. Learn it, break it, form an opinion about it. Just do not wire it into production until you know what happens when it goes wrong and who will fix it. The sandbox is for curiosity. Production is for things you trust.
Avoid drafty rooms
Close your resources and keep your architecture tidy. They are the same instinct at different scales.
# Leave the door open
conn = sqlite3.connect("data.db")
results = conn.execute("SELECT * FROM users").fetchall()
# conn never closed
# Close it behind you
with sqlite3.connect("data.db") as conn:
results = conn.execute("SELECT * FROM users").fetchall()
The with block closes the connection when it exits, even if something goes wrong. The same principle applies to your folder structure: functions that do one thing, files organized by what they are, no junk drawers. Tidiness at every scale makes the code easier to maintain and easier to hand off.
Add a Warm Greeting
When something goes wrong (and something will), your program should not slam the door in the user’s face. It should explain what happened and, where possible, what to do next.
# Before
def load_config(path):
with open(path) as f:
return json.load(f)
# After
def load_config(path):
try:
with open(path) as f:
return json.load(f)
except FileNotFoundError:
raise FileNotFoundError(
f"Config file not found at {path}. "
f"Check that the path is correct and the file exists."
)
except json.JSONDecodeError as e:
raise ValueError(f"Config file at {path} is not valid JSON: {e}")
Clear error messages will make you happy at 2 AM when production is down.
Leave a Paper Trail
Error handling tells you when something went wrong. Logging tells you what was actually happening before it did.
import logging
logger = logging.getLogger(__name__)
def calculate_monthly_interest(principal, annual_rate):
logger.debug(
"Calculating monthly interest",
extra={"principal": principal, "annual_rate": annual_rate}
)
daily_rate = annual_rate / 365
result = principal * daily_rate * 30
logger.info(
"Monthly interest calculated",
extra={"result": result}
)
return result
Telemetry is the same instinct at system scale. Instrument the things that matter: response times, failure rates, input ranges, unexpected paths. Not everything, but the things that will let you answer “what was the system doing when this broke?”
A codebase without observability is a black box. You can see the output. You cannot see what happened inside. That is a fine position to be in until it is not, and then it is very bad.
Leave a paper trail. Future you will be grateful.
The Long Way Is the Better Way
A codebase that still works clearly three years later is not an accident. It is the result of small, deliberate choices made consistently: names that communicate, documentation that explains the why, tests written before the code, tools chosen for stability, resources closed properly, errors handled with care, and enough instrumentation to understand what is actually happening at runtime.
None of this is glamorous. That is the point.