- Foundations
- Beginning Again: God’s Mercies in the New Year
- What Are My Defaults as a Programmer?
Every programmer has defaults.
Most of us just don’t notice them.
Defaults are the decisions we make without consciously deciding. They are the habits that sit beneath our awareness: the libraries we reach for instinctively, the architectural patterns we reuse, the shortcuts we allow ourselves when time is tight. Defaults are shaped by experience, pressure, team culture, tutorials we once followed, and mistakes we hope not to repeat.
Defaults are not inherently bad. In fact, they are unavoidable. Without them, every decision would require exhausting levels of deliberation. The danger lies not in having defaults, but in leaving them unexamined.
Unexamined defaults quietly make decisions on our behalf.
They decide whether we prioritise speed over clarity.They decide whether we document assumptions or leave them implicit.They decide whether edge cases are considered or postponed indefinitely.
In short: defaults shape foundations.
Defaults as Invisible Architecture
In software development, foundations are laid long before systems feel “real”. The earliest commits establish tone, expectations, and direction. Decisions about structure, naming, error handling, and data flow quickly become normalised. Once a project gains momentum, changing these choices becomes harder — not always technically, but socially and psychologically.
“Let’s fix it later” is a default many of us recognise. Sometimes it is necessary. Often, it quietly becomes policy.
Over time, defaults accumulate. They solidify into architecture. And architecture, once in place, shapes everything that follows. New developers adapt to it. Features are designed around it. Workarounds are created to accommodate it.
This is why inherited systems often feel heavy. You are not just dealing with code; you are dealing with years of unspoken decisions.
Asking “what are my defaults?” is an act of responsibility. It recognises that the small, repeated choices we make today become the constraints someone else lives with tomorrow — sometimes ourselves.
The Moral Weight of Defaults
It is tempting to think of defaults as purely technical concerns. But defaults carry moral weight because they affect people.
Consider a few common examples:
- Defaulting to minimal validation because “the data should be clean”
- Defaulting to accessibility later because “most users won’t need it”
- Defaulting to logging everything because “storage is cheap”
- Defaulting to copying patterns without understanding them
Each of these choices has consequences. Some affect users directly. Others affect colleagues, future maintainers, or organisations that must live with the system long-term.
Defaults answer ethical questions implicitly. They reveal whose time matters, whose needs are prioritised, and whose risks are acceptable.
This is especially true in data-driven systems. Defaults about missing values, thresholds, aggregation methods, and exclusions shape outcomes. They influence who is represented and who is invisible. Bias rarely enters systems loudly; it arrives quietly through defaults that “seemed reasonable at the time”.
Examining defaults is therefore not an academic exercise. It is a form of care.
How Defaults Are Formed
Defaults are rarely chosen deliberately. They emerge through repetition and reinforcement.
- Experience: What worked before becomes normal.
- Culture: Team norms shape acceptable practice.
- Pressure: Deadlines reward speed over reflection.
- Authority: Senior decisions become templates.
- Convenience: The easiest option becomes the standard.
None of these forces are malicious. But left unchecked, they create inertia. Over time, defaults stop being questioned not because they are optimal, but because they are familiar.
This is why junior developers often inherit practices without understanding their origins. “That’s just how we do it” replaces explanation. Curiosity is quietly discouraged in the name of efficiency.
Healthy teams resist this drift by making defaults visible.
Surfacing Your Defaults
So how do you actually examine your defaults?
It begins with paying attention to moments of automaticity — when you act without reflection. Ask yourself questions like:
- Why did I choose this approach first?
- What assumptions am I making about users, data, or context?
- Who benefits from this decision? Who bears the cost?
- What would change if this assumption were wrong?
These questions are not accusations. They are tools.
One useful exercise is to revisit early decisions after a project has matured. What felt sensible at the start may no longer be appropriate. Defaults that once saved time may now be liabilities.
Another is to invite challenge. Teams that normalise gentle questioning — “Why this way?” — tend to produce more resilient systems. Not because they avoid mistakes, but because they notice them sooner.
Defaults and Professional Maturity
There is a difference between beginner efficiency and mature efficiency.
Beginner efficiency often means moving quickly by copying patterns. Mature efficiency means knowing when and why to reuse — and when not to.
Professional growth involves replacing unconscious defaults with intentional ones. This does not slow you down in the long run; it speeds you up by reducing rework, confusion, and fragility.
Intentional defaults are explicit. They are documented. They are revisited. They are held lightly rather than defended rigidly.
They also change over time.
A default that served you well early in your career may no longer be appropriate as your responsibilities expand. Systems grow. Stakes increase. People depend on what you build in ways they didn’t before.
Maturity means allowing your defaults to evolve.
Defaults as Foundations
Foundations are not glamorous. They are rarely visible. They do not earn praise in demos or presentations. But they determine whether systems can grow without collapsing under their own weight.
Defaults are the quiet foundations of your technical life.
Examining them is not about self-criticism. It is about stewardship. It is recognising that your habits shape not only code, but culture — and that culture shapes outcomes.
As you begin this year, you do not need to overhaul everything at once. But you can start by noticing. By asking better questions. By choosing one default to make explicit and intentional.
Small changes at the foundation level compound over time.
And in both technology and life, what compounds quietly often matters most.
