Cognitive load is what matters • Hacker News Board

Re: Cognitive load is what matters

#21

Post by whstl » Sat, Aug 30, 2025, 2:45 PM UTC

Buttons840 wrote: post #4

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 aroun…

I believe you can build great abstractions in this kind of software, but if you want them to survive you gotta keep them any of that away from anything involving the business logic itself. You can only do this on product-like things: authn/authz, audit logs, abstractions over the database (CQRS, event sourcing), content/translation management, messaging infrastructure, real infrastructure. As soon as you allow anything from the business itself to affect or dictate those abstractions, you get shit again.

You're right that the business logic is gonna be messy, and that's because nobody really cares, and they can offload the responsibility to developers, or anyone punching it in.

On the other hand, separating "good code" and "bad code" can have horrible outcomes too.

One "solution" I saw in a fintech I worked at, was putting the logic in the hands of business people itself, in the form of a decision engine.

Basically it forced the business itself to maintain its own ball of mud. It was impossible to test, impossible to understand and even impossible simulate. Eventually software operators were hired, basically junior-level developers using a graphical interface for writing the code.

It was rewritten a couple times, always with the same outcome of everything getting messy after two or three years.

Re: Cognitive load is what matters

#22

Post by vjerancrnjak » Sat, Aug 30, 2025, 2:47 PM UTC

Buttons840 wrote: post #4

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 aroun…

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.

Re: Cognitive load is what matters

#23

Post by hibikir » Sat, Aug 30, 2025, 2:48 PM UTC

incognito124 wrote: post #5

marginalia_nu wrote: post #3

I think it's pretty tiresome that "smart authors" are blamed for writing complex code. Smart authors generally write simpler code. It's much harder to write simple code than complex for reasons that boil down to entropy -- there are simply many more ways to write complex code than simple code, and finding one of the simple expressions of program logic requires both smarts and a modicum of experience. If you try to do…

You reminded me of a rule of thumb that says: Keep the complexities in data structures and simplicity in algorithms

I have seen subscription systems built following that rule of thumb. It collapses pretty well, as the data structure then becomes impossible to engage with unless you are an expert, and the callers are never experts.

Things make more sense when the data structure lives in a world where most, if not all illegal atates become unrepresentable. But given that we often end un building APIs in representations with really weak type systems, doing that becomes impossible.

Re: Cognitive load is what matters

#24

Post by marginalia_nu » Sat, Aug 30, 2025, 2:49 PM UTC

baobabKoodaa wrote: post #17

marginalia_nu wrote: post #3

I think it's pretty tiresome that "smart authors" are blamed for writing complex code. Smart authors generally write simpler code. It's much harder to write simple code than complex for reasons that boil down to entropy -- there are simply many more ways to write complex code than simple code, and finding one of the simple expressions of program logic requires both smarts and a modicum of experience. If you try to do…

When an article like this uses the term "smart people", I'm always a bit confused if they mean actually smart people, or not-that-smart-people-who-think-highly-of-themselves. Because there's a lot more people in the latter category, and in my view they are the ones building unnecessary complexity into codebases. To clarify, when I say "not-that-smart-people", I don't mean "stupid people". You need to be beyond some b…

It takes intelligence to see where to make a change though.

If you make a change at the wrong place, you add more complexity than if you put the change in the right place. You often see the same thing with junior developers, in that case due to a limited mental model of the code. You give them a task that from a senior developer would result in a 2 line diff and they come back changing 45 lines.

Re: Cognitive load is what matters

#25

Post by ajzbzizkloll » Sat, Aug 30, 2025, 2:49 PM UTC

Buttons840 wrote: post #4

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 aroun…

Most business logic is “last mile” software. Built on top of beautiful abstractions that came not from an abstract idea of what’s correct but from painful clashes with reality that eventually provided enough clarity to build a good abstraction.

Sometimes last mile software turns into these abstractions but often not.

I’ve worked with very smart devs that try to build these abstractions too early, and once they encounter reality you just have a more confusing version of if statement soup.

Re: Cognitive load is what matters

#26

Post by makeitdouble » Sat, Aug 30, 2025, 2:50 PM UTC

Lowering the cognitive load by assigning temporary variables requires more thought and skill than credited here.

In particular these variables need to be extremely well named, otherwise people reading the code will still need to remember what exactly is abstracted if the wording doesn't exactly fit their vision. E.g.

> isSecure = condition4 && !condition5

More often than not the real proper name would be "shouldBeSecureBecauseWeAlsoCheckedCondition3Before"

To a point, avoiding the abstraction and putting a comment instead can have better readability. The author's "smart" code could as well be

  ```
  if (val > someConstant // is valid
      && (condition2 || condition3) // is allowed
      && (condition4 && !condition5) // is secure 
  ) {
      ...
  }
  ```

Re: Cognitive load is what matters

#27

Post by lxe » Sat, Aug 30, 2025, 2:51 PM UTC

Introducing intermediate variables is what I call "indirection". You're adding another step to someone reading the code.

Let's take a recipe:

   Ingredients:
   large bowl
   2 eggs
   200 grams sugar
   500 grams flour
   1/2 tsp soda

   Steps:

   Crack the eggs into a bowl. Add sugar and whisk. Sift the flower. Add the soda.

When following the instruction, you have to always refer back to the ingredients list and search for the quantity, which massively burdens you with "cognitive load". However, if you inline things:

   Crack 2 eggs into a large bowl. Add 200g sugar and whisk. Sift 500g of flower. Add 1/2 tsp soda.

Much easier to follow!

Re: Cognitive load is what matters

#28

Post by Buttons840 » Sat, Aug 30, 2025, 2:52 PM UTC

marginalia_nu wrote: post #16

Buttons840 wrote: post #4

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 aroun…

I honestly think that's pretty close to optimal for a lot of places. With business software it's often not desirable to have large sweeping changes. You may need some small change to a rule or condition, but usually you want things to stay exactly the way they are. The model of having a circle of ancient greybeards in charge of carefully updating the sacred code to align with the business requirements, while it seems…

It does work for awhile, until one day:

Project Manager: "Can we ship an order to multiple addresses?"

Grey Beard: "No. We'd have to change thousands of random if-statements spread throughout the code."

Project Manager: "How long do you think that would take?"

Grey Beard: "2 years or more."

Project Manager: "Okay, we will break you down--err, I mean, we'll need to break the task down. I'll schedule long meetings until you relent and commit to a shorter time estimate."

Grey Beard eventually relents and gives a shorter time estimate for the project, and then leaves the company for another job that pays more half-way through the project.

Re: Cognitive load is what matters

#29

Post by bathtub365 » Sat, Aug 30, 2025, 2:53 PM UTC

lxe wrote: post #27

Introducing intermediate variables is what I call "indirection". You're adding another step to someone reading the code. Let's take a recipe: Ingredients: large bowl 2 eggs 200 grams sugar 500 grams flour 1/2 tsp soda Steps: Crack the eggs into a bowl. Add sugar and whisk. Sift the flower. Add the soda. When following the instruction, you have to always refer back to the ingredients list and search for the quantity,…

When making a recipe you usually need to buy some or all of the ingredients. You also want to collect them all together beforehand since it makes things go a lot more smoothly. If they didn’t list them separately it would be easier to miss one.

Re: Cognitive load is what matters

#30

Post by marginalia_nu » Sat, Aug 30, 2025, 2:54 PM UTC

Buttons840 wrote: post #28

marginalia_nu wrote: post #16

Earlier quoted context omitted.

I honestly think that's pretty close to optimal for a lot of places. With business software it's often not desirable to have large sweeping changes. You may need some small change to a rule or condition, but usually you want things to stay exactly the way they are. The model of having a circle of ancient greybeards in charge of carefully updating the sacred code to align with the business requirements, while it seems…

It does work for awhile, until one day: Project Manager: "Can we ship an order to multiple addresses?" Grey Beard: "No. We'd have to change thousands of random if-statements spread throughout the code." Project Manager: "How long do you think that would take?" Grey Beard: "2 years or more." Project Manager: "Okay, we will break you down--err, I mean, we'll need to break the task down. I'll schedule long meetings unti…

Oh but the greybeards love meetings. There's nothing they'd rather do than spend days and weeks discussing how to affect changes, drawing boxes, writing documents, sending emails.