Good programmers worry about data structures and their relationships
Good software design, several engineers argue, starts with modeling data structures and their relationships rather than obsessing over algorithms or code flow. Commenters compare static typing (TypeScript, Rust, relational schemas, DDD-style modeling) and dynamic approaches (Rails, JSON/NoSQL, rapid prototyping), debating when strict types and carefully designed schemas pay off versus when they become brittle, overcomplicated or slow early iteration. The thread also highlights broader concerns about industry culture — from overuse of “type wizardry” and schemaless databases to a perceived decline in design rigor and a tendency to reward shipping code over understanding the domain.
Emphasis on Data Structures over Code
- Many agree with Torvalds’s quote: good design starts from modeling data and relationships, then writing minimal logic on top.
- Well-chosen structures can collapse complex algorithms into simple code and make systems easier to understand and refactor.
- Several highlight that once data is modeled cleanly, static vs dynamic typing matters less to understand the system.
Static Typing, TypeScript, and “Type-Driven Development”
- Some describe a workflow of defining types and data flow first, then wiring up UI or business logic, reporting large long-term payoffs.
- Others warn about “type astronauts” producing extremely complex TypeScript types with generics and conditional logic that are hard to maintain and debug.
- There’s disagreement whether such advanced type-level programming is a superpower or a source of fragile, bug-prone abstractions; code generation of “dumb” types is suggested as an alternative.
- Several note that static types can act like always-on tests, but also that you can design good data structures without static typing.
Strict vs Loose Types and Prototyping
- One camp favors rapid prototyping with loose or dynamic types, then tightening types and schemas once requirements stabilize.
- Others counter that strict types don’t hinder prototyping and that weak typing often moves complexity and errors to runtime.
- There’s discussion about API boundaries: some advocate strict types internally but looser coupling and simpler types at module or service interfaces.
Databases, Schemas, and Data Longevity
- Relational modeling and careful schema design are praised; changing schemas in production is seen as harder and more expensive than changing code.
- Poor database decisions (e.g., overloaded boolean columns) are cited as long-lived pain points.
- Some criticize schemaless stores as an escape hatch that often leads to multiple inconsistent “implicit schemas.”
- There’s debate on where to place complexity: richer database schemas vs simpler schemas with more complex queries or application logic.
OOP, Classes, and Domain Modeling
- Classes are broadly treated as data structures plus behavior; the key is designing the underlying data first.
- Domain-Driven Design is referenced: rich domain models and thoughtful entities/relationships vs anemic models that just shuttle primitives and JSON.
- Some stress that over-focusing on tactical patterns or purity can add complexity without commensurate value.
Meta: Design Culture and Incentives
- Several comments lament that industry rewards shipping code over doing careful design and domain analysis.
- There is concern that modern tooling and abundant hardware mask poor design, and that many teams treat schema and domain modeling as afterthoughts.