Good programmers worry about data structures and their relationships

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.