What I Believe

These disciplines represent my current understanding of what makes software development work. They’re informed by years of building systems, leading teams, and watching projects succeed and fail. They’re not rules to follow rigidly; they’re values to hold onto when pressure mounts and shortcuts tempt.

The first two disciplines address personal growth: how you develop yourself and accumulate genuine experience. The remaining five address technical practice: how you build software that delivers real value. Each discipline stands alone, but they reinforce each other. You can’t realign after discovery without genuine agreement to begin with, and you can’t reach genuine agreement without first testing your assumptions. The disciplines weave together into something stronger than any one of them alone.

---

1. Seek Hardship

If you are not sincerely seeking truth, you will never accept it.

There’s a difference between ten years of experience and one year repeated ten times. Accumulating experience means building new capabilities, taking on broader responsibilities, and establishing feedback loops that force growth. The discomfort signals learning.

Leadership emerges from behavior, not titles. Seek questions you don’t yet know to ask; the most dangerous gaps are the unknown unknowns. Maintain quality independent of approval; just because no one flagged your code doesn’t mean it’s quality work. Build others to build better products.

We learn by teaching. When you mentor less experienced developers, you create space for your own growth. As they learn to handle the work you do today, you create capacity to tackle the challenges your leaders face. This isn’t delegation to save time; it’s building organizational capability while advancing your own.

Going deeper: What Engineering Leaders Ask That Others Don’t examines the questions that reveal leadership characteristics.

---

2. Build to Learn

Real capability comes from building, failing, and fixing, not collecting badges.

Learning platforms sell completion checkmarks and the feeling of progress, not actual capability. That green badge feels good, but it doesn’t mean you can build something without the training wheels.

Watching someone else code doesn’t teach you to code, just like watching diving competitions doesn’t teach you to swim. Understanding concepts intellectually isn’t the same as being able to do. Sandboxed environments with no dependency conflicts, no environment setup, and no deployment challenges create the illusion of progress while keeping you dependent on structured guidance.

Real learning happens when you’re forced to make decisions without a script, when you get stuck and have to figure out why, when you realize your solution doesn’t scale and you need to rethink it. Build real projects, even terrible ones. That broken app taught you more than any polished tutorial. Read official documentation; framework creators document their tools better than third-party instructors. Study real code; thousands of production codebases are available to learn from.

The pattern is simple: do something, fail at it, learn why you failed, improve, repeat. No platform can give it to you because it requires struggle.

Going deeper: Learning Platforms Sell Badges, Not Skills explains why building beats consuming.

---

3. Genuine Discipline Comes from Core Values

Most project failures stem from broken values, not broken processes.

I’ve watched teams follow every ritual in the Scrum guide and still fail spectacularly. The standups happened, the retrospectives happened, the burndown charts looked great. But the team started with solutions before understanding needs, collected sign-offs instead of building genuine commitment, and chased task completion instead of honoring agreements. The process was perfect; the values were broken.

This discipline transcends methodology. You can practice AAA within Scrum, Kanban, Waterfall, or whatever your organization uses. The ceremonies are secondary; the values are primary.

The discipline also extends to technical work. When engineers integrate code, they align on intentions before modifying shared code, agree on interfaces and contracts, and apply those agreements in implementation. Test-driven development embodies this directly: write the agreement first (the test), then honor it in implementation. CI/CD automates the verification, and build failures surface broken agreements. The same values that prevent project failures prevent integration failures.

Organizations often respond to past failures by adding controls: approval gates, mandatory reviews, process checkpoints. These look like risk mitigation but often indicate a lack of trust in the underlying values. If you need strangling controls to prevent bad outcomes, the discipline isn’t there, and more process won’t fix that.

Going deeper: AAA Cycle explains the full discipline with practical guidance for each phase.

---

4. Measure Outcomes, Not Activity

When a measure becomes a target, it ceases to be a good measure. — Goodhart's Law

Velocity charts go up and to the right. Sprint completions hit 100%. The dashboard is green. And the product slowly dies because no one asks whether any of it mattered.

Activity metrics measure how fast you moved, not whether you moved in the right direction. Story points completed tells you nothing about problems solved. Burndown charts tell you nothing about customer satisfaction. Code coverage tells you nothing about whether the tests catch real bugs. These metrics are easy to track and satisfying to optimize, which makes them dangerous. Teams optimize what they measure, and measuring activity produces more activity.

Outcome measurement requires harder questions. Did the feature solve the actual problem? Would users notice if we removed it? Did the architectural change actually improve reliability, or did we just move complexity somewhere else? These questions don’t fit neatly into dashboards, but they’re the only ones that matter.

Going deeper: Why Your Agile Team Might Be Building on Hope, Not Discipline examines why frameworks that optimize for predictable metrics fail to deliver value.

---

5. Realign After Discovery

Test assumptions before committing. Realign when discovery demands prudent change.

The discipline starts with honesty: separate what you know from what you’re assuming, then test the critical assumptions before making commitments. Agree on what “done” looks like with explicit success criteria. When you discover new information during implementation, pause and reconsolidate the agreement. Discovery is inevitable; the question is whether you have the discipline to incorporate what you discover, or ship anyway because the timebox ends.

But realignment requires something more basic: the capacity to stop. Plan continuation bias, the tendency to continue with the original plan despite changing conditions, operates beneath every process improvement. When discovery arrives mid-implementation, the impulse to finish what you’re doing overrides the signal to reconsider. Recognizing this bias, and building environments where stopping is cheap and continuation past checkpoints is deliberate, is the prerequisite for any realignment discipline.

Going deeper: Why Your Agile Team Might Be Building on Hope, Not Discipline covers how to test assumptions and maintain continuous alignment. The Most Dangerous Sentence in Software Development explores the cognitive bias that prevents realignment from happening even when the process supports it.

---

6. Complete Features, Not Intervals

Time boundaries fragment work; feature boundaries deliver value.

Interval-based development organizes work around fixed time periods, not around completing features. When timeboxes become the primary organizing principle, they corrupt even well-aligned teams. Work fragments across sprint cycles. Features sit incomplete when boundaries arrive. Discovery mid-sprint forces awkward choices between shipping incomplete work or carrying it over.

The alternative is to organize around completing meaningful work. Shape features before committing to them: define clear boundaries, identify risks, clarify what “done” looks like. Give each feature appropriate time bounds based on its complexity, not universal sprint durations. Let work flow through the system when it’s ready, not when the calendar says so. When time bounds are exceeded, stop and reassess rather than pushing through.

Rhythm and tempo come from alignment and natural feature boundaries, not predetermined calendars. Features take as long as they take, bounded by constraints that force honest conversations when things run long.

Going deeper: Shaped Kanban: Complete Features, Not Sprints provides the complete framework for flow-based work with disciplined constraints.

---

7. Build for Change, Not Perfection

Systems that survive aren't written perfectly; they bend without breaking.

You will never get it right the first time. That’s not a failure; it’s how software development works. Requirements clarify through building. Edge cases emerge through usage. Performance bottlenecks surface under real load. Teams that treat first attempts as gospel spend months polishing solutions to the wrong problem.

The systems that survive are the ones designed to evolve. Single responsibility keeps components focused so changes don’t cascade. Dependency injection decouples implementations so they can be swapped. Configuration externalizes changeable behavior. Failing fast and loud surfaces problems immediately instead of hiding them.

These aren’t academic principles. They’re survival strategies. Perfect code written for yesterday’s requirements fails when reality shifts. Adaptable code survives because it expects change.

Going deeper: Adaptability Over Cleverness: What Makes Code Actually Good examines principles and practices for building systems that evolve.