Live data from Hacker News

Cognitive load is what matters

github.com

41–50 of 552 posts

Re: Cognitive load is what matters

#41
I think cognitive load has a lot more to do with the paradigm that the code is written in than any particular type of author's contribution to the code. For instance, the object-oriented paradigm by design increases cognitive load by encouraging breaking up otherwise straightforward logic into multiple interfaces, classes, and methods.

Re: Cognitive load is what matters

#43

Earlier quoted context omitted.

"the owners of the business logic do not treat the business logic with enough care." Certainly, there are such people who simply don't care. However I would also say that corporations categorically create an environment where you are unable to care - consider how short software engineer tenures are! Any even somewhat stable business will likely have had 3+ generations of owner by the time you get to them. Owner 1 is…

> consider how short software engineer tenures are! Employees aren’t fired. They leave for a 10% increase. Employees are the ones who seek always more in a short-termist way.

It would be short-termist if they had actual gains from their work other that salary. They don't.

They are acting rationally given companies don't seem to value long term expertise.

Now, if it was a worker- owned cooperative, that would be a different thing.

Re: Cognitive load is what matters

#44
post #2

The AI version of this is the degradation when the context window gets too large. The fix is the same too, summarize and reset.

AI does not have a cognitive load problem in remotely the same way people do. People can chunk and re-chunk info based on their skill and experience, but even the best AI just knows one thing - token length

Given the way attention works, it seems to me that AI has an even more concrete instantiation of cognitive load.

Re: Cognitive load is what matters

#45
The most important user of my temporary variables, à la "isValid" or "isSecure" is older/later me.

I could be adding a new feature six months later, or debugging a customer reported issue a week later. Especially in the latter case, where the pressure is greater and available time more constrained, I love that earlier/younger me was thoughtful enough to take the extra time to make things clear.

That this might help others is lagniappe.

Re: Cognitive load is what matters

#46
Cognitive load isn't a valid or useful concept: https://edtechdev.wordpress.com/2009/11/16/cognitive-load-th... https://www.tandfonline.com/doi/full/10.1080/00131857.2024.2...

There are separate contexts involved here: the coder, the compiler, the runtime, a person trying to understand the code (context of this article), etc. What's better for one context may not be better for another, and programming languages favor certain contexts over others.

In this case, since programming languages primarily favor making things easier for the compiler and have barely improved their design and usability in 50 years, both coders and readers should employ third party tools to assist them. AI can help the reader understand the code and the coder generate clearer documentation and labels, on top of using linters, test driven development, literate documentation practices, etc.

Re: Cognitive load is what matters

#47

Earlier quoted context omitted.

"the owners of the business logic do not treat the business logic with enough care." Certainly, there are such people who simply don't care. However I would also say that corporations categorically create an environment where you are unable to care - consider how short software engineer tenures are! Any even somewhat stable business will likely have had 3+ generations of owner by the time you get to them. Owner 1 is…

> consider how short software engineer tenures are! Employees aren’t fired. They leave for a 10% increase. Employees are the ones who seek always more in a short-termist way.

At the same time, the reason that employees leave on such a regular cadence is precisely because the companies they work for refuse to give them the salary increase that they could get by going elsewhere. Companies could solve this by giving commensurate raises.

Re: Cognitive load is what matters

#48
I spend a few decades in the industry and in even more teams. I think, the quality of code strongly correlates with the team's ability to articulate its members cognitive load and skills. In some projects it is just not opportune to point out a need to skill up, so everybody just accepts whatever in PRs and quality never gets any better.

On the other end of the spectrum you hear sentences starting with: "It would help me to understand this more easily, if ...".

Guess, what happens over time in these teams?

Re: Cognitive load is what matters

#49
Boy if I had a dollar for every “we’ve been doing it wrong” posts.

The issue with this stance is, it’s not a zero sum game. There’s no arriving to a point where there isn’t a cognitive load on the task you’re doing. There will always be some sort of load. Pushing things off so that you reduce your load is how social security databases end up on S3.

Confusion comes from complexity. Not a high cognitive load. You can have a high load and still know how it all works. I would better word this as Cognitive load increases stress as you have more things to wrestle about in your head. Doesn’t add or remove confusion (unless that’s the kind of person you are), it just adds or removes complexity.

An example of a highly complex thing with little to no cognitive load due to conditioning, driving an automobile. A not-complex thing that imparts a huge cognitive load, golf.

Re: Cognitive load is what matters

#50

Earlier quoted context omitted.

I generally don't mind documenting both when it's merited. Sometimes you need to clarify the why, occasionally you need to clarify the what. I think comments in general are underrated. You don't need to annotate every line like a freshman programming assignment, but on the other hand most supposed self-documenting code just isn't.

sometimes you do some wack magic in just one line of code, sometimes thats necessary for performance or because what you are trying todo is inherently wack magic. Example the fast inverse square from quake. Insane magic and if you just document does inverse square approximately people would freak out. So sometimes when wack magic is used explain the wack magic (as concise as reasonable)

Yup.

I've got a function the gist of which is

  if (!cond())
    return val;

  do {
    // logic
  } while (cond());

  return val;

This looks like it could be simplified as

  while (cond())
    // logic
  }
  return val;
But if you do you lose out on 20% of performance due to branch mispredictions, and this is a very hot function. It looks like a mistake, like the two are equivalent, but they are actually not. So it gets a comment that explains what's happening.
Post reply on HN