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

111–120 of 552 posts

Re: Cognitive load is what matters

#111

Post by james_marks »

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…

This is a helpful framing, thank you.

Something was bugging me after an interview with a potential hire, and now I can articulate that they were too much Einstein and not enough Mort for the role.

Re: Cognitive load is what matters

#112

Post by semiinfinitely »

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 essential complexity of those ideas. not easy and rare to see in practice

Re: Cognitive load is what matters

#113

Post by aDyslecticCrow »

reikonomusha wrote: post #101
aDyslecticCrow wrote: post #68

Earlier quoted context omitted.

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. Thoug…

I think the criticism is relevant because TFA isn't the first to exercise the term "cognitive load" in the context of computing. It's a term thrown around quite often, so we should cross reference its alleged meaning to literature. I myself find it to be a term that's effectively used as a thought-terminating cliche, sometimes as a way to defend a critic's preferred coding style and organization.

hmm. Using a term from formal science literature to loosely argue or back questionable arguments withe the ruse of scientific basis is a common issue. I pointed out that this article does not use the formal definition of the term, which you point out is itself an issue. Put that way i agree.

I think the article could have used a different term, or made a more clear declaration of what they specifically meant with the term to resolve this issue. Though i don't think it was done intentionally to deceive since the article makes no mention of the formal literature or theory of "cognitive load" to back its arguments.

Re: Cognitive load is what matters

#114

Post by wiseowise »

mdaniel wrote: post #88
Disposal8433 wrote: post #75

Earlier quoted context omitted.

> 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.

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

Both are made up bollocks for idiots to label people. Just write fucking code, solve business problems and go home.

Re: Cognitive load is what matters

#115

Post by conradkay »

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

> So, is pile-of-if-statements the best we can do for business software? You’ll enjoy the Big Ball of Mud paper[1]. Real world systems are prone to decay. You first of all start with a big ball of mud because you’re building a system before you know what you want. Then as parts of the system grow up, you improve the design. Then things change again and the beautiful abstraction breaks down. Production software is alw…

First link is broken

https://s3.amazonaws.com/systemsandpapers/papers/bigballofmu...

Re: Cognitive load is what matters

#116

Post by makeitdouble »

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.

What difference do you see from a Mort ?

If there is no inherent complexity, a Mort will come up with the simplest solution. If it's a complex problem needing trade-offs the Mort will come up with the fastest and most business centric solution.

Or would you see that Amanda refactoring a whole system to keep it simple above all whatever the deadlines and stakes ?

Re: Cognitive load is what matters

#117

Post by whatevertrevor »

mdaniel wrote: post #88
Disposal8433 wrote: post #75

Earlier quoted context omitted.

> 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.

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.

Re: Cognitive load is what matters

#118

Post by kaffekaka »

helge9210 wrote: post #66
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.

Definitely true.

I don't think it is malice or incompetence, but this happens too often to feel good.

Re: Cognitive load is what matters

#119

Post by Waterluvian »

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.”

Re: Cognitive load is what matters

#120

Post by gherkinnn »

makeitdouble wrote: post #116
darkstarsys wrote: post #69

Earlier quoted context omitted.

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.

What difference do you see from a Mort ? If there is no inherent complexity, a Mort will come up with the simplest solution. If it's a complex problem needing trade-offs the Mort will come up with the fastest and most business centric solution. Or would you see that Amanda refactoring a whole system to keep it simple above all whatever the deadlines and stakes ?

Mort is happy with an if soup. Amanda sees what the if soup ought to do and replaces it with a simple state machine and fixes two bugs along the way.
Post reply on HN