Good Software Development Habits

DRY, Duplication, and Abstraction

• Major debate around “copy-paste once, abstract on the third time” and “wonky parameters.”
• Many argue heavy parameterization (booleans/enums leading to combinatorial branches) is a strong smell and often means you unified things that should be separate.
• Others stress that premature abstraction is worse: duplication is acceptable when similarities are incidental and expected to diverge; abstraction should be reserved for logic that must stay in sync over time.
• Several comments reframe DRY as “don’t duplicate information / single point of truth,” not “never repeat similar code.”

Complexity, Simplicity, and Experience

• Repeated theme: inexperienced devs often produce accidental complexity via overuse of patterns, large interfaces, and over-DRYing.
• More experienced devs tend to favor simple, local code and tolerate some duplication.
• Some push back on oversimplified “juniors complex, seniors simple” narratives, noting that writing simple code is hard and often constrained by tooling and organization.

Function Design, Modules, and Naming

• Heavy function signatures and many flags are widely viewed as hard to maintain and test.
• Suggested alternatives: separate functions that call shared internal helpers; smaller, clearer abstractions; careful naming as a core design tool.
• Advice to put “orphan” functions into new modules is seen as context-dependent; can reveal future boundaries, but can also lead to scattered utilities and spaghetti if not curated.

Commits, Refactoring, and History

• Many defend small, atomic commits for easier revert, bisect, and cherry-pick, using tools like git add -p.
• Others note that actual production fixes are more often forward patches than clean reverts, and that “one big feature per commit” can be workable if planned.
• Target of “half of commits as refactors” is controversial: some see continuous refactoring as healthy; others see endless churn and lack of convergence.

Testing, Frameworks, and Mocks

• Strong disagreement with “don’t test the framework”: many rely on tests to detect breaking changes in dependencies.
• Suggested focus: test your system’s behavior end-to-end, which implicitly tests frameworks.
• Mixed views on mocks: some urge minimizing mocking and preferring “verified fakes” or real-ish integrations; others see mocking as essential for error paths and expensive or hard-to-reproduce conditions.
• “Testability implies good design” is challenged; some note test-friendly designs can be over-engineered, while very simple code may need fewer tests.

Technical Debt and Rewrites

• Simple three-type classification of tech debt is seen as incomplete; commenters emphasize cost-to-fix, ongoing penalty, and deadlines.
• Big-bang rewrites are widely considered risky; many advocate incremental, composable change, though some argue full or large-part rewrites are sometimes necessary.