Ten rules I break on purpose

These are not recommendations. They are confessions with attitude — each item names the cultural source of the rule so you know what you are rejecting.

“Never prefix your packages with your first name.” — NuGet guidance emphasizes discoverability and prefix reservations for trusted publishers, not outlawing personal prefixes—but the ecosystem norm skews corporate.¹
“Always write the ADR before the code.” — Architecture Decision Records formalize intent before implementation spikes; the pattern was popularized to capture why, not block prototyping.²
“Avoid global state.” — Structured programming dogma (Dijkstra-era) and functional idioms both warn against implicit mutable globals—yet every GUI toolkit eventually exposes process-wide singletons (Application.Current). Trade honesty about deliberate globals vs accidental ones.
“One repo per concern.” — Martin Fowler’s Monolith First essay argues microservice partitioning often premature; polyrepos vs monorepos remain tooling choices, not virtues.³
“Never optimize early.” — Donald Knuth’s oft-misquoted line appears in his 1974 Computing Surveys paper on structured programming: small efficiencies can hurt readability unless you know the critical 3%—not “never optimize.”⁴
“Always use the framework’s blessed path.” — Framework vendors document golden paths sized for median apps; extension points exist precisely because blessed paths fail edge domains (games, compilers, protocol stacks).
“Write tests first.” — Kent Beck crystallized TDD as red/green/refactor loops; empirical teams blend test-after for exploratory spikes—method books describe ideals, delivery adapts.⁵
“Keep posts short.” — Attention-economy blogging advice; incompatible with posts that carry citations and narrative arcs—pick your audience.
“Never ship a rant.” — Engineering culture prefers sanitized communications; incident reviews prove emotionally honest narratives accelerate learning when paired with facts.
“Be consistent.” — PEP 8 famously quotes “A foolish consistency is the hobgoblin of little minds” to defend breaking style when readability improves—consistency serves comprehension, not uniformity.⁶

The actual moral

Rules are heuristics from someone else’s scars. Steal the scars, question the slogans, keep the compiler happy.

References

Microsoft Learn — Package authoring best practices (IDs, namespaces, consumer trust). https://learn.microsoft.com/nuget/concepts/package-authoring-best-practices ↩
ADR GitHub organization — overview of Architecture Decision Records. https://adr.github.io/ ↩
Martin Fowler — Monolith First (2015). https://martinfowler.com/bliki/MonolithFirst.html ↩
Donald E. Knuth — Structured Programming with go to Statements, ACM Computing Surveys 6(4), Dec 1974 (premature optimization discussion). https://doi.org/10.1145/356635.356640 ↩
Kent Beck — Test Driven Development: By Example (Addison-Wesley). Summary reference via Martin Fowler’s bliki. https://martinfowler.com/bliki/TestDrivenDevelopment.html ↩
PEP 8 — Style Guide for Python Code (consistency vs readability). https://peps.python.org/pep-0008/ ↩