Algorithms we develop software by
“Gun to your head / 24‑hour” heuristic
- Many see it as a useful personal exercise to force focus on minimum viable solutions and break anchoring on large estimates.
- Strong pushback on using it as a management tool; people warn it can become pressure to cut corners, test in production, or sacrifice sleep.
- Some suggest rephrasing (“building is on fire”, “company dies tomorrow”) to avoid violent imagery.
- Concern: advice that sometimes reduces over‑engineering can also justify under‑engineering; judgment is still required.
“Write everything twice” / Rewriting
- Multiple commenters endorse rewriting features or systems as a way to clarify logic, pick better abstractions, and avoid large later refactors.
- Related idea: “spikes” — build a throwaway implementation to explore, then write the real one, often guided by tests.
- Counterpoint: business and PM stakeholders often see this as needless slowness or double cost; some argue the second pass is far cheaper and reduces long‑term cost.
- Some say they only partially rewrite (key parts, formatting, comments), others struggle to rewrite good or lost work due to motivation and déjà vu.
Unit tests vs. Design by Contract / System tests
- Heated subthread: one side calls unit tests wasteful and favors design‑by‑contract, assertions, fuzzing, and system/integration tests.
- They argue: most bugs stem from composition, not individual functions; contracts ship with software and can catch unexpected real‑world uses; unit tests are expensive, brittle, and often rewritten.
- Opposing view: contracts and unit tests are complementary, not substitutes; unit tests catch regressions before users see them and are essential for libraries or components without a single “system” context.
- References are made to studies and experience claiming both that tests improve quality and that over‑emphasis on tests can harm productivity; overall evidence in the thread is anecdotal and conflicting.
Abstractions, design, and cadence
- Good code is seen as mostly about choosing good abstractions, which often requires understanding the whole problem first.
- Danger of “analysis paralysis” is noted; experience helps balance upfront design vs. iterative implementation.
- Several mention workflows: break tasks into small, session‑sized chunks, keep code always working, and leave end‑of‑session brain‑dump notes.
Meta: lifetime, algorithms, and learning
- Some argue most software is rewritten or heavily refactored within years; “unchanged for 10 years” can signal bitrot and lost expertise.
- Others counter that long‑running, stable code can simply mean it does its job.
- A few remarks touch on how core algorithms are mostly stable and encapsulated in libraries; the “algorithms we develop software by” are more about process heuristics like those above.