Show HN: I built a reference site for the recurring hard problems in software
thehardparts.devHi 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. 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. 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. 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.