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

171–180 of 552 posts

Re: Cognitive load is what matters

#171

Post by cm2012 »

whatevertrevor wrote: post #117
mdaniel wrote: post #88

Earlier quoted context omitted.

For my frame of reference, do you think the Myers-Briggs Type Indicator are psycho-bullshit, too? Because I had characterized personas as a very similar "of course it's a generalization" and OP even said themselves "every engineer is a mix" but if you're coming from stance that bucketing people is disrespectful, then your perspective on MBTI would help me digest your stance

MBTI is absolutely bullshit, it's like one level above horoscopes and astrology, but very similar type of BS. There's also the Gallup crap that many corps were doing to evaluate the strengths and weaknesses of each employee so they could fit them into neat buckets such as "Leader" vs "Follower", as if these aren't skills people develop over time but actual personality traits.

Its kind of a common thing to say Myers-Briggs typing is useless because its pseudo-science. I dont think this is supported by the data in the way people think.

For one, many studies of identical twins raised in separate households show they have the same personality type at a much higher rate than chance.

Two, there are incredibly strong correlations in the data. In different surveys of 100k+ people, the highest earning type has twice the salary of the lowest type. This is basically impossible by chance.

The letters (like ENTJ) correlate highly to the variables of Big 5, the personality system used by scientists. Its just that it's bucketed into 16 categories vs being 5 sliding scales.

Scientific studies are looking for variables that can be tracked over time reliably, so Big 5 is a better measure for that.

But for personal or organizational use, the category approach is a feature, not a bug. It is much more help as a mental toolkit than just getting a personality score on each of the 5 categories.

Re: Cognitive load is what matters

#172

Post by an0malous »

bombela wrote: post #122
semiinfinitely wrote: post #112

The ability to create code that imposes low cognitive load on others not only is a rare and difficult skill to cultivate- it takes active effort and persistence to do even for someone who already has the ability and motivation. I think fundamentally the developer is computing a mental compression of the core ideas - distilling them to their essence - and then making sure that the code exposes only the minimum essenti…

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”

Re: Cognitive load is what matters

#173

Post by cm2012 »

Zarathruster wrote: post #150
mdaniel wrote: post #88

Earlier quoted context omitted.

For my frame of reference, do you think the Myers-Briggs Type Indicator are psycho-bullshit, too? Because I had characterized personas as a very similar "of course it's a generalization" and OP even said themselves "every engineer is a mix" but if you're coming from stance that bucketing people is disrespectful, then your perspective on MBTI would help me digest your stance

I'll leave it to others to make the argument for why Jungian psychology (and by extension, MBTI) is/isn't bullshit. But since nobody has mentioned the alternative yet, the framework used by anyone in any scientific capacity is the Big Five: https://en.wikipedia.org/wiki/Big_Five_personality_traits The link between programming and conscientiousness seems fairly straightforward. To fully translate Mort/Elvis/Einstein i…

Big 5 correlates to MBTI very closely in any case. With the exception of neuroticism.

Re: Cognitive load is what matters

#174

Post by winwang »

vdupras wrote: post #167

I don't know, I'm seduced by the elitist approach: code with a high cognitive load keeps mediocre developers away. Case in point: Forth. It generally has a heavy cognitive load. However, Forth also enables a radical kind of simplicity. You need to be able to handle the load to access it. The mind can train to a high cognitive load. It's a nice "muscle" to train. Should we care about cognitive load? Absolutely. It's a…

This is an interesting take. I have a somewhat orthogonal viewpoint -- rather than "heavy cognitive load", I think that going somewhat off-mainstream is good for attracting, on average, better devs. For example, it's likely that the average Haskell dev spends more time honing their craft than the average Java dev. The article kind of touches on this (e.g. FP "vs" the more popular OOP) with familiarity vs simplicity though.

Re: Cognitive load is what matters

#176

Post by RaftPeople »

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…

> It does work for awhile, until one day:

Your counter example assumes the people managing the code base are incompetent.

Wouldn't the rewrite fail for the exact same reason if the company only employs incompetent tech people?

Re: Cognitive load is what matters

#177

Post by fsckboy »

xmprt wrote: post #146
fsckboy wrote: post #144

Earlier quoted context omitted.

> AI can write extremely complex and unreadable code that works... until it doesn't. And then AI can fix it I'm not defending or encouraging AI, just saying that argument doesn't work

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 taking your time to get it right, so why should it be different with AI?

Re: Cognitive load is what matters

#178

Post by marginalia_nu »

jijijijij wrote: post #168
marginalia_nu wrote: post #76

Earlier quoted context omitted.

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.

Isn't branch prediction mostly a CPU thing? Do you have an example with corresponding assembly? It's not that I don't believe you about the performance impact, as I have observed the same with e.g. Rust in some cases, but I don't think it has a lot to do with the compiler judging what's more likely, but rather more or less "random" optimization differences/bugs. At least in my case, the ordering had nothing to do wit…

I don't have an assembly output for this particular case, but how I understand it is that the re-write basically turns it into two separate conditions, which means the branch predictor is free to model their outcomes separately.

In this case, the data is bimodal, depending on the chosen input, two likely outcomes exists. Either no looping is needed, or much looping is needed. This seemingly confuses the branch predictor when it's the same branch dealing with both scenarios.

Re: Cognitive load is what matters

#179

Post by jijijijij »

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

The challenge I have these days is deciding what belongs in code and what goes into design documentation and technical manuals. I generally find that comments in code should explain why the code is doing non-obvious things. “This gets memoized because it’s actually important to maintain referential identity for reason X.”

The problem is, a year later the obvious things are not obvious anymore :D
Post reply on HN