Ask HN: How can I practice designing data structures well? | Hacker News Reader

Ask HN: How can I practice designing data structures well?

1 pointmcdow1 comment

Linus Torvalds said: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships."

I want to improve my ability to design systems well. And I want to work towards building things with Linus' mindset.

When I work on a problem, I try my best to design it well ahead of time. But I typically don't have a good grasp of the entire system until after I have mostly implemented it. The nuances of the system are not clear until I have implemented it.

What are some techniques you use to understand a system before you build it? What are some good books that outline those techniques? Or is this a skill that one can only gain through trial and error or experience building systems?

M.A. Jackson's Principles of Program Design (1975) uses examples in COBOL, but some of its takeaways are

* A program should correspond 1:1 to its design. "Program structure [should] match the problem structure."

* Avoid flowcharts (flow of control) until the structure is designed. "Flowcharts tend to conceal structure."

* (Reuse of) components (before design) are a premature optimization.

* Write the program by composing primitives, not all of which are actually primitive operations for your machine.

---

(p. 35) In bottom-up design we say instead "this machine is not well-suited to my problem, because the elementary operations are too elementary; I shall therefore use the elementary operations to create a more powerful machine, and the operations of that machine to create one still more powerful, until I have a machine on which my problem can be easily solved".

---

Jackson believes many programs can be described as serial processing of files, so it's a philosophy I'm trying to understand.

Combined with Dubray's State-Action-Model (SAM), Miro Samek's quantum statecharts, and James Shore's nullables testing, it's a heady revitalization of the next couple decades.

> nuances of the system are not clear until I have implemented it

Yes, exactly. Each commit contributes to a graph of discovering each best move (balanced by time or pragmatics). It's hard to draw boxes and scribble when typing things out would surely straighten any gnarls.

Reply on news.ycombinator.com