Live data from Hacker News

Carl's Required Reading

carlkolon.com

21–30 of 31 posts

Re: Carl's Required Reading

#22
post #7

I personally hate YAGNI, because it so often leads to balkanized APIs that only implement the "needed" features and omit things that a reasonable person would expect because they weren't needed initially. Far better to have a clear and explicable model that is fully and consistently implemented.

That is something I observed too:

When you build a tool (physical or software) or an API (web or library) it should be easy to use. The easier it is to use the higher the probability that people will use it. So, if people build a kind of rudimentary thing and say that is all you need (which may be technically correct), then they do not optimize for likelihood of adoption/usage.

Re: Carl's Required Reading

#23

I have a similar list I like to share, had a few from Carl's list, will probably add a few from it. http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom... https://www.parsonsmatt.org/2017/10/11/type_safety_back_and_... https://lwn.net/Articles/336262/ https://tomasp.net/blog/2015/library-frameworks/ https://ratfactor.com/cards/not-quite-the-same https://matklad.github.io/2023/11/15/push-ifs-up-and-fors-do...

Ftfy:

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

https://www.parsonsmatt.org/2017/10/11/type_safety_back_and_...

https://lwn.net/Articles/336262/

https://tomasp.net/blog/2015/library-frameworks/

https://ratfactor.com/cards/not-quite-the-same

https://matklad.github.io/2023/11/15/push-ifs-up-and-fors-do...

Re: Carl's Required Reading

#25
the impact of recursivedoubts i.e htmx creator on software engineering practices and adhering to simplicity is monumental but the industry keeps heading towards complexity.

Re: Carl's Required Reading

#26
Decent list but the ORM thing makes me suspicious.

He links here as some kind of damning proof that ORMs are default bad.

https://openai.com/index/scaling-postgresql/

“It’s a poor craftsmen who blames their tools.”

My ORM rule of thumb: ORM for CRUD not Reports

If you are joining 12 tables for operational data, you have a design flaw. That’s a reporting query pattern.

Often temp tables, CTEs etc are needed as an immediate fix with redesign as a long term fix. The query planner simply can’t optimize that in a reasonable time or it’s beyond there scope if what it can optimize. Also their solution to “joining in memory” is common.

My DB query rule of thumb: If the query is hard for you to understand, it’s hard for the planner to understand.

Default to small fast simple queries and pipeline them together.

Re: Carl's Required Reading

#27
post #25

the impact of recursivedoubts i.e htmx creator on software engineering practices and adhering to simplicity is monumental but the industry keeps heading towards complexity.

Because everyone wants to Cargo Cult the architecture they see in Big Tech blogs.

“If we build like Google, we become Google”

I don’t know why a small company would want Google’s engineering problems.

Re: Carl's Required Reading

#28
post #17
post #15

Microservices grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug ^ This is the best and funniest paragraph of text that I’ve read this year

I'm a fan of the t-rex: > given choice between complexity or one on one against t-rex, grug take t-rex: at least grug see t-rex That section reminds me of The Litany Against Fear.

Hah, indeed!

  "I must not complect.
  Complexity is the mind-killer.
  Complexity is the little-death that brings obliteration.
  I will face complexity and I will permit it to pass over me and through me.
  And when it has gone past, I will turn the inner eye to see its path.
  Where the complexity has gone, there will be nothing.
  Only I will remain."

  — Litany Against Complexity
I made that up in blog post that feels aligned with Carl's world-view. The Litany appears here in the post: https://www.evalapply.org/posts/writing-practices-to-10x-eng...

Re: Carl's Required Reading

#29

Decent list but the ORM thing makes me suspicious. He links here as some kind of damning proof that ORMs are default bad. https://openai.com/index/scaling-postgresql/ “It’s a poor craftsmen who blames their tools.” My ORM rule of thumb: ORM for CRUD not Reports If you are joining 12 tables for operational data, you have a design flaw. That’s a reporting query pattern. Often temp tables, CTEs etc are needed as an imme…

Your DB query rule goes against my experience.

Sometimes longer and more complex queries run much, much faster. The users complain about "complexity", but when they see the performance comparison they change their minds.

Post reply on HN