Principles

Principle: a fundamental truth or proposition that serves as the foundation for a system of belief or behavior or for a chain of reasoning.

Mindset and life

#

• Always improve.
• Always adapt.
• Accept that nothing is perfect.
• Know what you want and don’t want.
• Always remain positive.
• Surround yourself with positive people.
• Avoid spending your time on negative thoughts.
• Spend no time complaining.
• Spend time working on interesting things.
• Spend your time with happiness generators, stay away from happiness drainers.
• Always limit how much time you spend dwelling on problems and mistakes.
• Do not spend too much time thinking about hypothetical situations.
• Do not invent problems that do not need solving.
• Be proactive rather than reactive.
• Minimize your regret.
• Overcome fear by doing the thing you fear.
• Constraints force creativity.
• Stay humble; any edge you have is small and temporary.
• You define the meaning of your own life.
• Tolerating bad behavior harms the good.
• When the assumptions behind a trusted practice change, reevaluate the practice itself, not just how you execute it.
• Effort cannot close a gap between two different capacity categories.
• Feeling informed is not being informed.
• Work you did not choose takes longer because nothing pulls you through it.
• Do not set your standards by the behavior of the people around you.

Focus and attention

#

• Effectiveness over efficiency.
• Work on things that matter.
• Work on fewer things to get them to completion.
• Focus on input, not output.
• Stop starting, start finishing.
• Focus on the critical path and let minor tasks wait.
• Put your time where you get rewarded for the effort.
• Periodically measure and review how you spend your time.
• For each recurring activity, explicitly decide whether to cut, reduce, keep, increase, or add it.
• Curating the right input is not enough; ensure the consumer actually attends to it.
• When a recipient ignores information it was already given, the fix is subtraction, restructuring, or repositioning, never more volume.
• Context-switching carries a save/restore cost proportional to task complexity; chunk long-horizon work to shrink the cost of re-entering it.
• Optimize for signal, not coverage; filtering is designable where reading speed is fixed.
• Focus defends itself on work you want to do; distractions win only on work you resent.
• Treat attention, not generation, as the scarce resource.
• Parallelize generation, serialize judgment.
• The number to watch is not how much you delegate but where the freed time lands.

Decisions and prioritization

#

• Priority, priority, priority.
• Say no early and often.
• If everything is top priority, nothing is.
• When working on projects with unclear objectives, always define your KPIs.
• Order your backlog; do not merely prioritize it.
• Priority describes what a task is, not when you will get to it; separate classification from scheduling.
• Allocate capacity across priority levels rather than only ever working the single top item.
• Apply the 80/20 rule: identify the few inputs that produce most of the results and plan around them.
• Build funnels, not lists: discard most candidates at the cheap stages, confidently and without guilt.
• Prioritization frameworks are a forcing function for conversation, not an oracle; the value is in the disagreement they surface, not the score they produce.
• Every item you keep carries a cognitive tax; a small, well-ordered list beats a large one, so archive aggressively.
• Treat urgency as a hypothesis from someone with an incentive to inflate it, not as a fact.
• Filters decay; periodically re-audit what you discarded and what you kept.
• When overwhelmed, discard your list and rebuild it fresh from your own judgment of what matters most.
• Do not delay difficult decisions indefinitely.
• Prefer action over a perfect decision.
• Know when to abandon goals.
• Spend your best energy on your most important decisions.
• Batch similar decisions to stay in one cognitive mode and reduce switching cost.
• How you decide matters more than what you decide; the meta-process compounds while the specific answer does not.
• Do not relitigate settled decisions under pressure; defer to a written process.
• Convert “impossible” into a priced menu of options; never present a refusal without the cost of overcoming it.
• Invert, always invert.
  • Spend less time trying to be brilliant and more time trying to avoid obvious stupidity.
  • https://fs.blog/2013/10/inversion/
• Use analogies when reasoning about complex ideas.
  • Sometimes equivalents make it easier to reason about a problem when translated into a different domain.
• Understand the root cause; do not brute-force solutions.
• Judge changes by their consequences and reversibility, not by their category.
• Prefer feedback from reality over prediction.
• Prefer the right information over more information.
• Be adaptive to relevant change and robust against irrelevant change.
• The cost of gathering information is always less than the cost of building the wrong thing.
• Consistently wrong is worse than inconsistently right.
• Activity is not progress; do not confuse motion with movement.
• The skill is in choosing the right work, not in doing the work.
• Observed behavior reveals process better than stated process; read the artifact over the doc.
• Between two failure modes, choose the cheaper to recover from.
• Define success criteria before the experiment starts, not after.
• Truthful labeling forces truthful conversations about what you are explicitly not doing.
• A backlog is a commitment queue, not a wish list.
• Every item must trace to a parent goal; orphaned work is bloat.
• Never inflate priority labels; inflation destroys the meaning of every label.
• Distribute reversible decisions; give irreversible ones a single owner.
• When acting becomes cheap, deciding must become more careful; being wrong has not gotten cheaper.
• Start cheap and escalate on failure signals; pay premium prices only on the hard tail.
• When attempts are cheap, race them and keep the winner.
• Prefer risks you can audit over risks you must take on faith.
• Some work is faster done than delegated.

Planning and estimation

#

• Always plan, even if you don’t end up using the plan.
• Begin with the end in mind, then plan backwards.
• Define what “done” looks like before you start.
• Plan with the most realistic scenario in mind.
• Plan by preventing the worst scenarios from happening.
• Reduce risks and unknowns early in your projects.
• Separate discovery (figuring out what to do) from delivery (doing it); unrefined items do not get scheduled.
• Set a fixed time budget (appetite) that defines scope, rather than estimating an unbounded duration.
• Eliminate work by specifying better, not by running more of it.
• Separate the vision (direction) from the commitment (contract); never conflate them.
• Quantify everything you can, then measure it.
• Calibrate your estimates against your past performance.
• Keep buffers for when estimates are wrong.
• Use relative comparisons when absolute estimates are too hard.
• Prefer coarse discrete scales over false precision.
• Schedule the longest task first to minimize total completion time.
• Use robust statistics (median over mean) when measurements may be contaminated by outliers.
• Predictability is worth more than heroism.
• Track throughput and stability as independent axes; speed without stability is a house of cards.
• Fast feedback beats comprehensive feedback.
• Divergent estimates signal unspecified scope, not bad estimators.
• The serial fraction of your process caps all parallel speedup.
• Shrink long-term problems into chunks you can start and finish quickly.
• Technical debt has no natural advocate; fund it by fixed allocation.
• Manage the outcome, not the activity; effort signals die when execution is cheap.
• A delegable outcome names what becomes true, how it will be checked, and what it may cost.
• When exploration is nearly free, the failure mode is premature documentation.

Leverage and compounding

#

• Separate activities into compounding and depreciating; protect compounding work and delegate or automate depreciating work.
  • Use the two-year test: ask whether continuing an activity leaves future you more or less valuable.
  • Overweight durable activities; underweight ephemeral ones.
• Invest effort where the blast radius is largest, not where the noise is loudest.
• The constraint never disappears; it just moves.
• Move with the bottleneck as it shifts.
• The binding constraint is usually the layer you are not looking at.
• Continuously optimize.
• Periodically simplify; do not only add.
• Have people depend on you less and less.
• Avoid repeating yourself constantly.
• Prefer standard solutions for solved problems; spend your energy where it differentiates.
• Anything that scales with size must be optimized to grow slower than size.
• Make yourself unnecessary at the layer you occupy.
• Improving anything other than the binding constraint is theater.
• Automation relocates work to a different layer; it does not remove it.
• Per-unit effort cannot match entropy that is produced faster than you can process it; operate on the system that produces the units, not the units.
• Specification compounds; review is a non-compounding backstop.
• Delegation is not free even when the delegate is free; delegating a compounding activity forgoes the practice that built the judgment to evaluate it.
• Produce work that is cheap to accept, not merely plentiful.
• Unaccepted work is inventory; it rots the longer it waits.
• Discipline buys a constant factor; only replication buys a curve.
• Point surplus capacity at lightening the constraint, not at feeding it.
• When you cannot add capacity at the bottleneck, choke the demand arriving at it.
• The durable asset is the system that produces the work, not the work it produces.
• Every check you write is attention you never have to spend again.
• Audit the rules rather than each output; a bad rule produces bad outputs forever.
• Promote experts from reviewing outputs to owning the rules.
• The line between compounding and depreciating moves; re-sort it regularly.
• Delete scaffolding when the capability it propped up arrives.

Learning and knowledge

#

• Learn new things everyday.
• There are no shortcuts to mastery; learn the fundamentals.
• Specialize first, then generalize.
• Deliberately practice the things you are weak at.
• Study failures, not just successes.
• Answering your own questions exposes what you do not yet understand.
• Learn from prediction errors (surprise), not just from outcomes.
• Build the mental model before you need it under pressure; you cannot grow one on demand.
• Reading is cheaper than writing; it transfers everywhere and builds the model without demanding fluency.
• Survey many sources in parallel, not sequentially, to surface cross-cutting patterns.
• Consume on demand, not on schedule; knowing where to find something when you need it beats knowing it now.
• Every new source or commitment should displace an existing one, not stack on top.
• Copy, transform, combine.
• Model those who have already achieved what you want and identify the gap between your state and theirs.
• You cannot prompt a mental model into existence under time pressure; foundation knowledge cannot be acquired just-in-time.
• Honest failures teach; soft failures train nothing and accumulate until they become outages.
• Transfer reasoning, not conclusions; your map expires, the navigation does not.
• Parallel consumption surfaces patterns that sequential decay hides.
• The last non-delegable job is articulating taste, what the automation is for.
• Only people can tell you that you are wrong; every other system replays decisions you already made.
• Judgment is grown by contact with consequences, not transferred by explanation.
• Judgment does not persist without exercise.
• Automating junior work cuts the input to the pipeline that produces senior engineers.
• When automation removes the struggle, the learning must become deliberate.
• When automation removes a learning channel, rebuild it deliberately off the critical path.
• Generation is free; understanding is not, and it is the part that appreciates.
• Maintain living knowledge, not snapshots; put recurring questions on a loop.
• A strong practice preference is scar tissue from a real failure somewhere else.
• Study how others reason about problems, not just their solutions.
• Much of what we call judgment is undocumented procedure, discoverable by attempting to automate it.

Memory and notes

#

• Always write down why.
• Externalize your memory: write down what is in your head.
• Capture first, organize later; keep a low-friction buffer separate from structured notes.
• Notes you never review are wasted; build a review loop into your information system.
• Memory of past interactions is signal to be retained, not bias to be eliminated.
• An unwritten decision’s half-life is one new person; write decisions down to make them travel.
• A meeting that ends without a written decision will have to be held again.
• Record rationale at decision time; a decision record written after the fact is fiction.
• A wrong claim in a durable document grows authority every day it survives.

Communication and writing

#

• Do not engage in fruitless debates or one-sided confrontations.
• It is more important to have support for your ideas than for them to be perfect or right.
• Use progressive disclosure: lead with a summary, offer detail only on request.
• Writing does not degrade as it passes through people; speech does, so write decisions down.
• Make stakeholders co-authors of decisions so they defend them rather than overturn them.
• Distribution is half the work of production; effort spent producing is wasted without matching effort on distribution.
• Be a source, not an echo.
• Proof of work is the signal that survives: show costly effort, not assertion.
• Narrow beats broad; specificity is what cannot be synthesized.
• Stories transfer; advice without context does not.
• Candor earns authority; admitting error builds trust faster than defending perfection.
• A fast, clear no is a kindness; silence is the answer that swells the queue.
• When instructions fail, the fix is usually subtraction; over-specification is the common decay.
• Writing exposes the gaps that live conversation silently repairs.
• Arrive with proposals others can amend, not verdicts they can only review.
• Answer the argument, not the volume.
• Demonstrate the hardest case, not the happy path; edge examples carry the most information.
• The judgment behind the words is the product; the prose is the cheap part.
• Fluency without experience produces echo.
• Factor ideas like code; extract and reuse instead of rewriting duplicates.
• Write ideas self-contained so they survive outside their original context.
• Volume makes you more of the flood, not more visible within it.

Systems and automation

#

• Have a structured process for everything you do that is written down and updated as it changes.
• Use checklists for routine critical tasks.
• Establish a manual process before automating it.
• When you repeatedly catch the same issue, automate the check.
• If you can describe a problem precisely, you can automate it.
• Engineer workflows around your own cognitive limits instead of trying to power through them.
• Use tools to amplify your judgment, not replace it.
• Distinguish between friction that wastes time and friction that prevents mistakes.
• The metric you optimize determines the system you get.
• Encode your judgment into the layer everything passes through; your leverage scales with encoded surface area, not hours.
• Encode standards as gates and defaults, not as opinions; a standard runs whether or not anyone agrees with it.
• Make the right behavior the path of least resistance: tax what you want less of, subsidize what you want more of.
• Convert preferences into machine-checkable invariants where possible.
• Grant autonomy gradually, based on accumulated evidence of reliability, not optimism.
• Make systems slow learners, not judges; require accumulated evidence before changing state.
• Bound autonomous systems on two independent axes: cost (budget) and capability (least privilege).
• Make operations idempotent so they are safe to re-trigger.
• Make failures visible; silent failures are worse than no automation at all.
• Design systems so that gaming them produces the behavior you wanted anyway.
• A system people do not trust is a system that does not run, regardless of how well it verifies.
• Make every automated decision legible: which rule fired, what it checked, who owns it.
• Keep a kill switch; the cost of not having one is an unconstrained runaway.
• When a measure becomes the target, it ceases to be a good measure.
• Drift rate must stay below the cleanup rate for a system to stay net-positive over time.
• Triage before review: decide whether something deserves your attention before you evaluate it.
• Use AI to triage AI.
• Variability is the enemy of scale.
• A system is a decision made once.
• A process that only works when nothing ever goes wrong is not a process, it is a countdown.
• An overloaded gate fails silently: rubber-stamped work feels reviewed without being reviewed.
• A queue grows without bound whenever intake outpaces processing.
• Every fixed cost at a gate incentivizes batching, and batching makes changes riskier.
• A human gate is also a human attack surface.
• Never let a system approve changes to itself; someone must audit the auditors.
• Either read a change deliberately or merge it on signals; do not fake the reading.
• Measure the gap between what a process claims to do and what its participants actually do.
• Every approval gate that adds no information is pure delay.
• A process earns its keep only if it forces thinking people would otherwise skip.
• One tool doing many jobs does each poorly; give each property its own dedicated check.
• Make critics adversarial and single-purpose: reward finding a failure, never approving.
• Defend a process with production outcomes, never with “a human looked at it”.
• Separate deciding from executing, with different privileges, so neither runs away.
• Autonomy over an enumerated, closed list is auditable; autonomy over open-ended judgment is not.
• Apply the cheapest filters first; sort with cheap signals before spending deep attention.
• Feed every manual correction back into the artifact that produced it.
• Keep an exit from every dependency; switching should be a configuration change, not a rewrite.
• Scaling a flawed system repeats the flaw in every instance at once.

Software and code quality

#

• Every line of code is a liability.
• Invest in quality early because it compounds.
• The quality of the output is bounded by the quality of the input, context, or foundation that produced it.
• Front-load human effort where mistakes are cheapest to fix; the later you catch a defect, the more expensive it is.
• When a class of problem recurs, fix the source once so the correction compounds across every future occurrence.
  • Fix at the source once, or fix at the symptom forever.
• Make quality a property of your constraints and system, not of individual reviewers.
• Separate the valuable act from the gating ritual; satisfy the function rigorously and let the form follow.
• Separate execution from review to avoid bias.
• When a reviewer shares the generator’s blind spots, agreement proves almost nothing; verify with independent signals.
• Use structurally diverse verification methods so failures do not correlate.
• Do not trust the output; trust the verification system behind it.
• Most production failures occur at integration points, not within components.
• Isolate components with different scaling characteristics so each can scale independently.
• Make coordination optional, not mandatory; components should function independently.
• Distinguish high-interest debt from low-interest debt; treat them differently.
• Defects flow downstream and multiply; fixes must flow upstream to compound.
• Fix the process, not the product.
• When the builder is a machine, code quality is bounded by specification quality.
• Move verification upstream to the specification; review is the latest, most expensive stage to catch an issue.
• Accountability lives upstream in the decisions that guided the work, not in whoever scans the diff at the end.
• Write the verification and acceptance criteria before the code exists.
• Right context, curated and ordered, beats more context; attention dilutes.
• Implicit assumptions are the most dangerous context gaps because you do not notice them.
• The value lives in the tails, not the mean; average-case metrics hide tail erosion.
• Keep the oracle separate from generation, and broader than the happy path.
• Subjective requirements are discovered by contact with the artifact, not enumerated in advance.
• For generated artifacts, the prompt is the source code.
• Maintain code as if no author can be asked.
• Optimize code for readability; it is read far more often than it is written.
• Concentrate what changes often; let what rarely changes be broad.
• Verification speed sets the ceiling on safe generation speed.
• Treat every passing test suite as a claim about coverage, not proof of correctness.
• Split verification (built right) from validation (right thing); they need different stages and owners.
• Review what a change does, not what it looks like.
• As generation gets cheaper, spend review on intent and substance, not style.
• Make reversibility a structural property of how changes are made, not a review-time judgment.
• Gate changes by blast radius and reversibility, not by artifact type.
• Write the contracts before fanning out workers; fixed interfaces make integration mechanical.
• Trust comes from attack, not inspection.
• Understand opaque artifacts by what they do, not what they are.
• You can own only as much code as you can understand.
• Keep the spec, delete the code.
• If you cannot answer why-questions without the tool, you generated the artifact rather than built it.
• Bad output is the truest signal about where the input is incoherent.

Teams and collaboration

#

• Structure (tooling, architecture, repository layout) should follow the coordination and trust structure, never lead it.
• The right size for any unit is the smallest that can own a coherent domain end-to-end.
• When something belongs to everyone, it belongs to no one; diffuse ownership causes decay.
• Every healthy system needs both entropy generators (visionaries) and entropy controllers (stewards).
• There is an optimal team size; beyond it, adding people decreases output.
• Push decisions down: let workers resolve their own ambiguities and escalate only above a defined threshold.
• Consistency beats optimality for conventions and practices.
• Treat practices and opinions as hypotheses to test, not identities to defend.
• Never discourage anyone who continually makes progress no matter how slow.
• Fix the system, not the person; structure determines behavior.
• Culture must be actively transmitted during growth; it dilutes by default.
• During a crisis, one person owns the response; everyone else supports.
• During incidents, diagnose first and assign blame never; save blame for the post-mortem.
• Hiding a boundary is not the same as removing it.
• Onboarding must scale sublinearly; keep the ratio of onboarded to onboarders above 1:1.
• Create new teams when the current team is at capacity, not when the project is already late.
• A team moves at the pace of its least coordinated member.
• Trust is the strongest predictor of team performance; a trusting team of mediocre engineers outperforms brilliant engineers who do not trust each other.
• Treat resistance as information; skeptics map where your system is weakest.
• The real architecture is the role structure of the contributors, not the dependency graph of the packages.
• Every harsh rule is a scar on reviewer time; trace each rule to the wound it prevents, and delete the ones that have none.
• The first disagreement a group resolves sets the template for every disagreement that follows.
• A team’s standard is set by whatever ships first, not by what it agrees is best.
• Absence of objection measures busyness, not consent.
• Name the cost of what you absorb, or the team learns absorption is free.
• People choose deferred shared costs over immediate personal ones, even when the deferred cost is larger.
• Tolerating post-decision overrides turns the process into veto by the most stubborn.
• A team directed by one person has one person’s judgment, no matter how many people it employs.
• Hoarding decisions manufactures the incompetence that justifies hoarding them.
• Name norm-violating behavior early, before it calcifies.
• Judge people by their total cost, not their visible output.
• Never reciprocate aggression; matching tone turns a disagreement into a status fight.
• Measure knowledge risk by re-acquisition time, not by how many heads hold the system.
• Treat planned absences as load tests of whether the system survives without its owner.
• Add a human when the context no longer fits in one head.
• Hire for where a person will disagree with you, not for how much they produce.
• The appearance of specialists marks the point where generalists can no longer cover the surface.
• Delegate execution without delegating ownership.
• A handoff is complete when the receiver can explain the work, not when the artifact runs.
• No owner, no merge.
• Before removing a role, name its function; the function survives the role.
• When producing is nearly free and owning is not, people produce more than they will maintain.

Strategy and business

#

• When you outsource an outcome, you also outsource the decisions that produce it.
• Invest during good times so you can survive the bad; maintain a consistent strategy through both.
• Compete on what cannot be cloned.
• When everyone can build anything, deciding what to build becomes the differentiator.
• Low barriers to entry drive margins toward zero.
• When the cost to produce falls below the cost to consume, the consumer becomes the bottleneck.
• For an automated workforce, the evaluation pipeline is the critical asset, more than the agents it tests.
• Coherence is a job that must be owned, not a byproduct of good local decisions.
• A feature is a probe, not a deliverable.
• Trust is the slowest thing in a product to reproduce.
• Trust is the only distribution channel that does not saturate.
• Sell the outcome, not the tool.
• When everyone is fast, advantage shifts to the quality of the feedback signal.
• Make whoever creates the volume carry the cost of making it reviewable.
• When the cost to create falls below the cost to review, review becomes the resource to defend.
• Put the cost back where the benefit was captured.
• Build alternatives; dependence is what gives aggression its leverage.
• When the layer you mastered commoditizes, move your value up a layer.