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

331–340 of 552 posts

Re: Cognitive load is what matters

#331

Post by rhameetman »

neonrider wrote: post #257

Love it. Make code accessibility a first-class citizen. Turn the rule books and their principles into guidelines . A smart coder knows to follow rules. A master knows code is meant to be read and develops contextual awareness for when and why to break a rule, or augment it, as the case may be. So, reintroduce judgment and critical thinking in your coding practice. Develop an intuitive feel for the cognitive costs and…

> Make code accessibility a first-class citizen.

This is a good article but the main thing that bugs me about it is that the author completely disregards germane overhead.

Germane overhead is about recognition and practice and, at scale, it matters just as much.

Intrinsic and extraneous overhead is about the information itself and how it’s presented.

Germane overhead is about the receiver so in order to make code accessibility a first-class citizen you can’t ignore it.

Re: Cognitive load is what matters

#332

Post by swat535 »

exclipy wrote: post #264

This was my main takeaway from A Philosophy Of Software Design by John Ousterhout. It is the best book on this subject and I recommend it to every software developer. Basically, you should aim to minimise complexity in software design, but importantly, complexity is defined as "how difficult is it to make changes to it". "How difficult" is largely determined by the amount of cognitive load necessary to understand it.

I've long given up on trying to find the perfect solution for Software. I don't think anyone has really "cracked the code" per se. The best we have is people's wisdom and experiences.

Ultimately, context, industries and teams vary so greatly that it doesn't make sense to quantify it.

What I've settled on instead is aiming for a balance between "mess" and "beauty" in my design. The hardest thing for me personally to grasp was that businesses are indeterministic whereas software is not, thus requirements always shifts and fitting this into the rigidity of computer systems is _difficult_.

These days, I only attempt to refactor when I start to feel the pain when I'm about to change the code.. and even then, I perform the bare minimum to clean up the code. Eventually multiple refactoring shapes a new pattern which can be pulled into an abstraction.

Re: Cognitive load is what matters

#333

Post by zakirullin »

xiphmont wrote: post #329

This is actually some wonderful work that succinctly explains a lot of my experience. Much of how I was formally taught to program is counterproductive to the big picture the second someone else has to understand the code. It's part of the reason that I hate dealing with Rust and C++, and breathe a sigh of relief when the codebase I need to suck into my head is good old C. C offers fewer ways to hide all the working…

Nice to hear that it resonates with your experience. I liked C for the exact same reason. Switched to Golang recently, simplicity is cherished here too!

Re: Cognitive load is what matters

#334

Post by dwattttt »

an0malous wrote: post #172
bombela wrote: post #122

Earlier quoted context omitted.

And if you do it really well, people think it must have been such an easy problem to solve all along. Since everything always appears so obvious in insight. While the castle of cards of unfathomable complexity is praised for visibly hard work and celebrated with promotions.

“When you do things right, people won’t be sure you’ve done anything at all”

But only if you make it look like an electrical thing

Re: Cognitive load is what matters

#335

Post by lokar »

YZF wrote: post #316
exclipy wrote: post #264

This was my main takeaway from A Philosophy Of Software Design by John Ousterhout. It is the best book on this subject and I recommend it to every software developer. Basically, you should aim to minimise complexity in software design, but importantly, complexity is defined as "how difficult is it to make changes to it". "How difficult" is largely determined by the amount of cognitive load necessary to understand it.

The problem is no set of rules can replace taste, judgement, experience and intuition. Every rule can be used to argue anything. You can't win architecture arguments. I like the article but the people who need it won't understand it and the people who don't need it already know this. As we say, it's not a technical problem, it's always a people and culture problem. Architecture just follows people and culture. If you…

I found the book helpful as a way to organize and express what I already knew

Re: Cognitive load is what matters

#336

Post by AstroBen »

zahlman wrote: post #290
bsenftner wrote: post #270

Earlier quoted context omitted.

Which is why I consider DRY (Don't Repeat Yourself) to be an anti-rule until an application is fairly well understood and multiple versions exist. DO repeat yourself, and do not create some smart version of what you think the problem is before you're attempting the 3rd version. Version 1 is how you figure out the problem space, version 2 is how you figure out your solution as a maintainable dynamic thing within a cha…

DRY isn't about not reimplementing things; it's about not literally copying and pasting code. Which I have seen all the time, and which some might find easier now but will definitely make the system harder to change (correctly) at some point later on.

DRY is about concepts, not characters. Don't have multiple implementations of a concept

If you choose to not copy paste the code you better be damn sure the two places that use it are relying on the same concept, not just superficially similar code thats yet to diverge

Re: Cognitive load is what matters

#337

Post by dlivingston »

braebo wrote: post #328
YZF wrote: post #316

Earlier quoted context omitted.

The problem is no set of rules can replace taste, judgement, experience and intuition. Every rule can be used to argue anything. You can't win architecture arguments. I like the article but the people who need it won't understand it and the people who don't need it already know this. As we say, it's not a technical problem, it's always a people and culture problem. Architecture just follows people and culture. If you…

I’m accustomed to this principle as a musician, so it’s been interesting to see it withstand my journey into software.

Can you expand on this?

Re: Cognitive load is what matters

#338

Post by ivanjermakov »

> Let's say we have been asked to make some fixes to a completely unfamiliar project.

How real is this use case? Unless you switch projects really often, this is like a week per two years.

Perhaps we should focus on solving problems that are hard by nature, not by experience of a developer or other external factors.

Re: Cognitive load is what matters

#339

Post by ivanjermakov »

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…

Such comments are never maintained. Implementation will change 5 times this year and the comment will get stale and confusing.

At my current projects we drop all code comments except for some really tricky logic and very high level docs.

Re: Cognitive load is what matters

#340

Post by AstroBen »

fsckboy wrote: post #177
xmprt wrote: post #146

Earlier quoted context omitted.

I'm talking about cases where even AI can't fix it. I've heard of a lot of stories where people vibe code their applications to 80% and then get stuck in a loop where AI is unable to solve their problems. It's been well documented that LLMs collapse after a certain complexity level.

you were also talking about the future (as AIs get better and better). as of now AIs cannot write code too complex for better programmers to understand. your point holds for armies of low skill programmers, but you're just raising a fear and haven't come close to proving the case you're trying to make. We already know as counterweight that being first to the market with very substandard code generally wins over takin…

> We already know as counterweight that being first to the market with very substandard code generally wins

..we do?

Who created short stories as used in Tiktok/IG?

The first touch screen phone?

First social media app?

Was Google the first?

I mean I almost see the opposite of what you're saying..

Post reply on HN