←back to thread

Cognitive load is what matters

(github.com)
1455 points nromiun | 3 comments | 30 Aug 25 12:58 UTC | HN request time: 0s | source
Show context
Buttons840 ◴[30 Aug 25 14:15 UTC] No.45074873[source]▶
I'm probably one of the "smart developers" with quirks. I try to build abstractions.

I'm both bothered and intrigued by the industry returning to, what I call, "pile-of-if-statements architecture". It's really easy to think it's simple, and it's really easy to think you understand, and it's really easy to close your assigned Jira tickets; so I understand why people like it.

People get assigned a task, they look around and find a few places they think are related, then add some if-statements to the pile. Then they test; if the tests fail they add a few more if-statements. Eventually they send it to QA; if QA finds a problem, another quick if-statement will solve the problem. It's released to production, and it works for a high enough percentage of cases that the failure cases don't come to your attention. There's approximately 0% chance the code is actually correct. You just add if-statements until you asymptotically approach correctness. If you accidentally leak the personal data of millions of people, you wont be held responsible, and the cognitive load is always low.

But the thing is... I'm not sure there's a better alternative.

You can create a fancy abstraction and use a fancy architecture, but I'm not sure this actually increases the odds of the code being correct.

Especially in corporate environments--you cannot build a beautiful abstraction in most corporate environments because the owners of the business logic do not treat the business logic with enough care.

"A single order ships to a single address, keep it simple, build it, oh actually, a salesman promised a big customer, so now we need to make it so a single order can ship to multiple addresses"--you've heard something like this before, haven't you?

You can't build careful bug-free abstractions in corporate environments.

So, is pile-of-if-statements the best we can do for business software?

replies(23): >>45074916 #>>45074936 #>>45074945 #>>45075059 #>>45075089 #>>45075095 #>>45075106 #>>45075135 #>>45075188 #>>45075195 #>>45075392 #>>45075443 #>>45075463 #>>45075515 #>>45075547 #>>45075846 #>>45076426 #>>45077189 #>>45077500 #>>45077548 #>>45078893 #>>45079553 #>>45080494 #
1. vjerancrnjak ◴[30 Aug 25 14:47 UTC] No.45075106[source]▶
There are many ways code can get simpler even with ifs.

If you find yourself sprinkling ifs everywhere, try to lift them up, they’ll congregate at the same place eventually, so all of your variability is implemented and documented at a single place, no need to abstract anything.

It’s very useful to model your inputs and outputs precisely. Postpone figuring out unified data types as long as possible and make your programming language nice to use with that decision.

Hierarchies of classes, patterns etc are a last resort for when you’re actually sure you know what’s going on.

I’d go further and say you don’t need functions or files as long as your programming is easy to manage. The only reason why you’d need separate files is if your vcs is crippled or if you’re very sure that these datetime handlers need to be reused everywhere consistently.

Modern fullstack programming is filled with models, middleware, Controllers , views , … as if anyone needs all of that separation up front.

replies(1): >>45075705 #
2. soulofmischief ◴[30 Aug 25 15:59 UTC] No.45075705[source]▶
These abstractions become a toolset for creating a program that naturally evolves as new goals and constraints are introduced. It also allows other engineers to understand your code at a high level without reading it from top to bottom.

If your code ever has the possibility of changing, your early wins by having no abstraction are quickly paid for, with interest, as you immediately find yourself refactoring to a higher abstraction in order to reason about higher-order concepts.

In this case, the abstraction is the simplicity, for the same reason that when I submit this comment, I don't have to include a dictionary or a definition of every single word I use. There is a reason that experienced programmers reach for abstractions from the beginning, experience has taught them the benefits of doing so.

The mark of an expert is knowing the appropriate level of abstraction for each task, and when to apply specific abstractions. This is also why abstractions can sometimes feel clumsy and indirect to less experienced engineers.

replies(1): >>45081662 #
3. vjerancrnjak ◴[31 Aug 25 09:05 UTC] No.45081662[source]▶
Haven’t seen even something like opinionated frameworks work well with their initial abstractions.

Even file interfaces in most programming languages don’t come with pipelining. Most are leaky abstraction.

Most abstractions also deal with 1 thing instead of N things. There’s no popular http server that supports batch request processing.

Async-await is a plague of an abstraction.

Abstracting something like trivial if statements is not a problem. The best transaction of all, passing a function to a function is underused.