Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cognitive load is what matters

github.com

Post reply on HN
Print view View original

61–70 of 552 posts

Re: Cognitive load is what matters

#61

Post by Buttons840 »

dsego wrote: post #53
Buttons840 wrote: post #19

It's been said: "Document the why , not the what ." I have a hard time separating the why and the what so I document both. The biggest offender of "documenting the what" is: x = 4 // assign 4 to x Yeah, don't do that. Don't mix a lot of comments into the code. It makes it ugly to read, and the context switching between code and comments is hard. Instead do something like: // I'm going to do // a thing. The code // do…

> x = 4 // assign 4 to x Ah, the chat gpt style of comments. > Instead do something like: The only negative is that there is a chance the comment becomes stale and not in sync with the code. Other coders should be careful to update the comment if they touch the code.

If the what becomes stale, you can tell. If the why becomes stale (and it can become stale), you'll never know, unless the what is also included.

Re: Cognitive load is what matters

#64

Post by oh_my_goodness »

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…

You can't depend on the business people to understand the business logic clearly enough to explain it to the implementers. That will never happen. They may understand it themselves, but they're not coders and they can't write requirements for code.

Instead, at least one implementer needs to get hands dirty on what the application space really is. Very dirty. So dirty that they actually start to really know and care about what the users actually experience every day.

Or, more realistically for most companies, we insist on separate silos, "business logic" comes to mean "stupid stuff we don't really care about", and we screw around with if statements. (Or, whatever, we get hip to monads and screw around with those. That's way cooler.)

Re: Cognitive load is what matters

#65

Post by azhenley »

noen wrote: post #18

This article reminds me of my early days at Microsoft. I spent 8 years in the Developer Division (DevDiv). Microsoft had three personas for software engineers that were eventually retired for a much more complex persona framework called people in context (the irony in relation to this article isn’t lost on me). But those original personas still stick with me and have been incredibly valuable in my career to understan…

I had a lot of fun in DevDiv!

Re: Cognitive load is what matters

#66

Post by helge9210 »

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…

You can carefully pick an order of features to build in a way, that every new feature will invalidate an abstraction correctly implementing all the previous features.

Re: Cognitive load is what matters

#67

Post by Buttons840 »

atomicnumber3 wrote: post #31
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…

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

What you say is true, but I meant the product owners are the one who don't fully weigh the cost of their decisions.

I once tried to explain to a product owner that we should be careful to document what assumptions are being made in the code, and make sure the company was okay committing to those assumptions. Things like "a single order ships to a single address" are early assumptions that can get baked into the system and can be really hard to change later, so the company should take care and make sure the assumptions the programmers are baking into the system are assumptions the company is willing to commit to.

Anyway, I tried to explain all this to the product owner, and their response was "don't assume anything". Brillant decisions like that are why they earned the big bucks.

Re: Cognitive load is what matters

#68

Post by aDyslecticCrow »

edtechdev wrote: post #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…

The linked articles seem to primarily criticize three things about connotative load theory;

- Difficult to measure and therefore a hard or impossible to empirically study. (a bad scientific theory)

- Its application to education and learning theory which where a lot of other techniques are more proven.

- The idea that it's a primary mechanism of human learning, which has had a-lot of research showing otherwise.

Though those points seem valid, this article does not concern itself deeply with this concept. The word "mental strain" or "limited short term memory" could have been inserted in place of "cognitive load", and the points raised would be valid. In effect the article argues we should minimize the amount of things that need to be taken into consideration at any given point when reading (or writing) code. This claim is quite reasonable irrespective of the scientific bases of CTL which it takes its wording from.

So i don't think your criticism is entirely relevant to this article, but raising it does help inform others about issues with the used wording if they happen to want to learn more.

Re: Cognitive load is what matters

#69

Post by darkstarsys »

noen wrote: post #18

This article reminds me of my early days at Microsoft. I spent 8 years in the Developer Division (DevDiv). Microsoft had three personas for software engineers that were eventually retired for a much more complex persona framework called people in context (the irony in relation to this article isn’t lost on me). But those original personas still stick with me and have been incredibly valuable in my career to understan…

Clearly they were missing Amanda, the engineer who's had to review others' terrible code (and her own) for 20 years, and has learned the hard way to keep it simple. She knows she's writing code mostly for people to read, not computers. Give me a small team of Amandas any day.

Re: Cognitive load is what matters

#70

Post by darkstarsys »

darkstarsys wrote: post #69
noen wrote: post #18

This article reminds me of my early days at Microsoft. I spent 8 years in the Developer Division (DevDiv). Microsoft had three personas for software engineers that were eventually retired for a much more complex persona framework called people in context (the irony in relation to this article isn’t lost on me). But those original personas still stick with me and have been incredibly valuable in my career to understan…

Clearly they were missing Amanda, the engineer who's had to review others' terrible code (and her own) for 20 years, and has learned the hard way to keep it simple. She knows she's writing code mostly for people to read, not computers. Give me a small team of Amandas any day.

And as a manager/CTO, the way to do this is to give the devs time to think about what they're doing, and reward implementation clarity (though it's its own reward for Amandas).
Post reply on HN