Show HN: I built a reference site for the recurring hard problems in software

Show HN: I built a reference site for the recurring hard problems in software(thehardparts.dev)

9 points by ludovicianul 21 days ago | 3 comments

Hi HN, I've been working on this for a while and it was hard to decide when to stop, either on the way information is presented or when to stop with adding entries. It's not meant as a blog, but rather as a reference that keeps growing.

Link: https://thehardparts.dev

Currently I've created 4 main section:

- Failure Modes: ways project go wrong

- Red Flags: early signals that are worth taking seriously

- Tech Decisions: common and not so common trade-offs for hard choices

- Playbooks - guided approach for situations that repeat

I've also focused on creating links between them to show how connected many things are: a red flag usually precedes a failure mode, which might connect to a forced decision, etc.

Some entry points to give you an idea:

- The Invisible Deadline: a date that exists socially but not explicitly enough to manage honestly

- Eveyone Asks The Same Person: when one person becomes the default source of truth

- Build a Practical Rollback Strategy: how to build a reliable rollback strategy

It has 151 entries across the 4 sections.

Curious what you think about the content, format, grouping.

stocktech 21 days ago |

I'll echo that the UI design is cool. I do think it could be improved to help parse information. Right now, it feels like everything is bold, highlighted, italicized, or something denoting how important it is. This is made worse as every UI element is also bold and highlighted.

ludovicianul 20 days ago | |

As this is already distilled information, rather than an essay/blog post, my thought was that every part is important. Just like you take notes from a course and use different UI elements to signal how each thing is important.

jdw64 21 days ago |

I really like your use of neobrutalism it’s one of my favorite UI styles. Your site is great overall, and I learned a lot from it, especially the playbook section.

I’ve been reading through the SQL and NoSQL parts, and I really enjoyed them. Personally, I would have loved to see more detailed examples or code snippets to make the concepts even clearer.

From my own experience, NoSQL has worked well for blog-style sites where flexibility matters, while SQL tends to be a better fit for payments or larger, more structured systems. So it was interesting to see how you approached that distinction.

Thanks for putting this together — it’s a great resource.