Top all-time · #2701
Max Chernyak
Personal blog · max.engineer · on HN as hakuninprogrammingcareer
Max Chernyak's personal blog at max.engineer covers programming and career. Since 2020, 17 different Hacker News readers have linked it 70 times, most often “Don't build a general-purpose API to power your own front end”. It is still writing: the last post was on 2026-09-03, and you can follow it by feed.
The latest entries posted on Max Chernyak
Most-linked posts?
- Don't build a general-purpose API to power your own front end7 people · 9 mentions · first linked 2021-09-13
- Long Term Refactors3 people · 6 mentions · first linked 2023-11-22
- CMS Trap (2013)3 people · 6 mentions · first linked 2020-06-24
- Don't Build a General Purpose API (4 Years Later)3 people · 5 mentions · first linked 2025-12-11
- Mindful Code Reviews2 people · 6 mentions · first linked 2021-10-04
- Adventures in Ruby-esque type enforcement2 people · 5 mentions · first linked 2023-05-14
- Getting Answers from a Big PDF with RubyLLM2 people · 2 mentions · first linked 2025-05-17
What Hacker News says?
Agreed, I wrote more in depth about it a few years ago: https://max.engineer/maintainable-code
Comment linking /maintainable-code
on “Cognitive load is what matters”Submitted Writing maintainable code is a communication skill as a story · 297 points
HN discussionI've made a personal doc tool based on Mistral OCR API at first, and then switched to Gemini Flash for the same price inline, or half price using batch API, and the difference is night and day. Mistral doesn't even come close on anything non-trivial. Longer story here: https://max.engineer/ringbinder
Comment linking /ringbinder
on “Mistral raises €3B”Submitted Don't build a general-purpose API to power your own front end as a story · 128 points
HN discussionThe only point I was making is that short name signals that nothing unusual is going on, and long name signals that you have to pay extra attention. I never suggest to replace a comment with a long name. Here's my 4 reasons to leave a comment: https://max.engineer/reasons-to-leave-comment Comments are crucial for "why", and additional context. Name shouldn't go beyond "what". More on that here: https://max.engineer/…
Comment linking /maintainable-code
on “Clean Code vs. A Philosophy Of Software Design”Submitted Long Term Refactors as a story · 65 points
HN discussionBecause of the simplicity, flexibility and power of the hypermedia programming model. - simplicity: e.g. something like active search can be implemented with a few attributes: https://htmx.org/examples/active-search/ - flexibility: e.g. because of the uniform interface, versioning is much less of an issue - power: e.g. deep linking is trivial Additionally, there is increasing awareness[1] that Application APIs and D…
Comment linking /server-informed-ui
on “Django, HTMX and Alpine.js: Modern websites, JavaScript optional”Submitted Human Slop as a story · 19 points
HN discussionAgree with all of this, and recommend this process for engineering tech debt: https://max.engineer/long-term-refactors In short: maintain a list of long term refactors that everyone's gradually working on, without necessarily showing it in the ticket tracking system.
Comment linking /long-term-refactors
on “Backlog size is inversely proportional to how often we talk to customers”Submitted Three Reasons Not to Implicitly Memoize as a story · 11 points
HN discussionVery relatable. Within the context of a single startup this definitely applies. However, in the span of your career, I like to ask — do you want to get fast at writing good code or writing bad code? You won't get perfect code of course, but at the very least you can learn to churn out code that's easy to change. It's not the same thing as expressive code, but it does the job at a startup. (I wrote another article[1]…
Comment linking /cms-trap
on “Writing maintainable code is a communication skill”Submitted Failover to Human Intelligence as a story · 6 points
HN discussionI have seen people arguing that you shouldn't be using the same API endpoints for front-ends and for integration. I can see arguments both ways though... https://max.engineer/server-informed-ui
Comment linking /server-informed-ui
on “Htmx and Web Components: A Perfect Match”Submitted Don’t Build a General Purpose API to Power Your Own Front End (2021) as a story · 6 points
HN discussionYeah, that was too short a response, sorry I was bouncing around a lot in the thread. The essay I linked to somewhat agrees w/your general point, which is that hypermedia is (mostly) wasted on automated consumers of REST (in the original sense) APIs. I don't think it's a bad thing to split your hypermedia API and your JSON API: https://htmx.org/essays/splitting-your-apis/ (NB, some people recommend even splitting yo…
Comment linking /server-informed-ui
on “Triptych Proposals”Submitted Adventures in Ruby-esque type enforcement as a story · 5 points
HN discussionI wrote about this a few years ago.[0] The gist to avoiding premature over-architecting is to keep sticking with as static/hardcoded behavior as possible to meet the requirements. Just make sure it’s well organized and cleanly written in your language of choice. Then over time add configurability to that behavior as specs change. Architecture is easy to change not when it correctly predicts future change (almost imp…
Comment linking /cms-trap
on “Ask HN: How to avoid over-engineering software design for future use cases?”Submitted Long Term Refactors as a story · 4 points
HN discussionI've written up some rules that I've successfully applied in my teams. https://max.engineer/mindful-code-reviews
Comment linking /mindful-code-reviews
on “Code reviews do find bugs”Submitted Ringbinder – Lowkey Best Tool for Personal Docs as a story · 3 points
HN discussionWrote last year about the fact that AIs can be down, and what that might mean: https://max.engineer/failover-to-hi
Comment linking /failover-to-hi
on “Claude partial outage”Submitted Don't Build a General Purpose API (4 Years Later) as a story · 3 points
HN discussionThis is a good "what not to do". A while ago I wrote a "what to do"[1], which could serve as a good complement to this article. [1]: https://max.engineer/mindful-code-reviews
Comment linking /mindful-code-reviews
on “Code review antipatterns”Submitted Getting Answers from a Big PDF with RubyLLM as a story · 3 points
HN discussionHere's a pretty good essay by Max Chernyak on why using a generic JSON api to power your application's front end is a bad idea. https://max.engineer/server-informed-ui tl;dr: Your JSON api has to figure out: - How to predict and enable all possible workflows - How to avoid N+1 requests for awkward workflows - How to test functionality, performance, and security of every possible request - How to change the API witho…
Comment linking /server-informed-ui
on “The Aha Stack”Submitted Adventures in Ruby-esque type enforcement as a story · 3 points
HN discussionI don't disagree, dynamic languages require better writing skills, so for example, in case of bilingual teams, metadata helps bridge the language barrier. However, if your team is good at expressing how/what/why[1] in your dynamic language, you will not have much issue answering what things are. Again, there are costs with either choice. [1]: https://max.engineer/maintainable-code
Comment linking /maintainable-code
on “What Dynamic Typing Is For”Submitted Maintainable Code Explains Itself as a story · 3 points
HN discussionI built portrayal[1] (a much simpler replacement for those dry libs), and was also experimenting[2] with runtime-enforced types based on this lib. My general thoughts is that declaring types in Ruby is unnecessarily complicated, because you're basically just running values through pieces of boolean logic, and nothing else. Might as well make that explicit, which is what my experiment did. I didn't however publish th…
Comment linking /portrayal-guards-poc
on “Lowtype: Elegant Types in Ruby”Submitted Reasons Not to Implicitly Memoize as a story · 3 points
HN discussion
