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

71–80 of 552 posts

Re: Cognitive load is what matters

#71

Post by mewpmewp2 »

xyzzy123 wrote: post #36
hmottestad wrote: post #9

Earlier quoted context omitted.

Been playing with Codex CLI the past week and it really loves to create a fix for a bug by adding a special case for just that bug in the code. It couldn't see the patterns unless I pointed them out and asked it to create new abstractions. It would just keep adding what it called "heuristics", which were just if statements that tested for a specific condition that arose during the bug. I could write 10 tests for a sp…

Also they hedge a lot, will try doing things one way, have a catch / error handler and then try a completely different way - only one of them can right but it just doesn't care. Have to lean hard to get it to check which paths are actually used and delete the others. I am convinced this behaviour and the one you described are due to optimising for swe benchmarks that reward 1-shotting fixes without regard to quality.…

That's a really good point. I was wondering why some of the LLMs were trained to try to pass things so sloppily constantly. Writing mock data, methods and pretending as if the task is complete and everything is great, good to go. They do seem to be trained just to pass some sort of conditions sadly and it feels somehow to me that it has got worse as of late. It should be relatively easy to reward them for writing robust code even if it takes longer or won't work, but it does seem they are geared towards getting high swe benchmarks.

Re: Cognitive load is what matters

#72

Post by claytongulick »

makeitdouble wrote: post #26

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

I try to structure functions and validations like this in a early-return list at the top of a function.

    if(val
The author mentions this technique as well.

I find it particularly useful in controller API functions because it makes the code a lot more auditable (any time I see the same set of conditions repeating a lot, I consider whether they are a good candidate for middleware).

I try to explain this to newer developers and they just don't get it, or give me eyerolls.

Maybe sending them this article will help.

Re: Cognitive load is what matters

#73

Post by brokencode »

marginalia_nu wrote: post #50
mastermage wrote: post #38

Earlier quoted context omitted.

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

That feels like.. something the compiler should be optimizing for you? I would certainly be among those questioning this code.

Re: Cognitive load is what matters

#74

Post by bravetraveler »

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…

Animal Farm, but with a twist

Re: Cognitive load is what matters

#75

Post by Disposal8433 »

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…

> three personas for software engineers

The kind of psycho-bullshit that we should stay away from, and wouldn't happen if we respected each other. Coming from Microsoft is not surprising though.

Re: Cognitive load is what matters

#76

Post by marginalia_nu »

brokencode wrote: post #73
marginalia_nu wrote: post #50

Earlier quoted context omitted.

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

That feels like.. something the compiler should be optimizing for you? I would certainly be among those questioning this code.

The compiler can't know from the code alone which branch is more likely. This is a property of the input data and not the code. Really advanced JIT compilers can sometimes do those types of optimizations, but this is a fairly rare scenario.

Re: Cognitive load is what matters

#77

Post by SoftTalker »

makeitdouble wrote: post #26

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

They can all be right. I agree assigning variables doesn't help much more than good comments. But worth doing if they are needed more than once in the same scope. But do we need "is valid", "is allowed", and "is secure" more than once in differnt scopes? They should probably functions then. Do we always need all three considered together? Then they should be a single function. Are there ever places where condition2 or condition 3 are not allowed? More complexity.

Even simple examples like this get complicated in the real world.

Re: Cognitive load is what matters

#78

Post by soulofmischief »

vjerancrnjak wrote: post #22
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 prog…

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.

Re: Cognitive load is what matters

#79

Post by aDyslecticCrow »

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…

I like to call that a leaky abstraction. The author used "UNIX I/O" as a great example. It perfectly hides the complexity and abstraction is such a way that the programmer never needs to know the internals. It has sealed all the juicy complexity in a watertight container that the user of the abstraction never needs to peak inside of.

The auth example may not be. You may need to do validatePassword(user) for passwordCorrect(user) to be true, which then forces you to open up a hole in the abstraction that is userAuthorized(request) and peak inside. userAuthorized() has leaked out its logic, it has failed as an abstraction. Its a box with 3 walls and no roof that blocks visibility to important logic rather than hides away the complexity.

Re: Cognitive load is what matters

#80

Post by perlgeek »

oh_my_goodness wrote: post #62

I would love to have four chunks in my head. I feel like I have to start writing when I get to #3.

I think the origin of the "four chunks in short-term memory" comes from giving people tasks to calculate some numbers, and seeing after how many digits they became noticeably slower.

A fact that you need to remember about code might use up more or less short-term memory in a human brain compared to a digit or a number, so don't be ashamed if your number is 3 instead of 4.

I also think that my working memory was better when I was 20ish, now at 41 I already feel less fits in and I forget it faster.

Post reply on HN