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

401–410 of 552 posts

Re: Cognitive load is what matters

#401

Post by awesome_dude »

jonahx wrote: post #397
awesome_dude wrote: post #394

Earlier quoted context omitted.

> Our coding standards require that functions have a fairly low cyclomatic complexity. The goal is to ensure that we never have a a function which is really hard to understand. https://github.com/fzipp/gocyclo > * We also require a properly descriptive header comment for each function and one of the main emphases in our code reviews is to evaluate the legibility and sensibility of each function signature very careful…

> he weirdest example I have ever had to deal with - a team had unilaterally decided that the 'else' keyword could never be used in code. Not weird at all: https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea...

Well, I found it weird - the else keyword has been a stalwart of programming for... several decades now.

Maybe one day we will abstract it away like the goto keyword (goto is a keyword in Go, and other languages still, but I have only seen it used in the wild once or twice in my 7 or 8 years of writing Go)

Goto is still used in almost every language, but it's abstracted away, hidden in loops, and conditionals (which Djikstra said was a perfectly acceptable use of goto), presumably to discourage its direct use to jump to arbitrary points in the code

Re: Cognitive load is what matters

#402

Post by awesome_dude »

arbol wrote: post #400
awesome_dude wrote: post #394

Earlier quoted context omitted.

> Our coding standards require that functions have a fairly low cyclomatic complexity. The goal is to ensure that we never have a a function which is really hard to understand. https://github.com/fzipp/gocyclo > * We also require a properly descriptive header comment for each function and one of the main emphases in our code reviews is to evaluate the legibility and sensibility of each function signature very careful…

I can understand why else is sometimes not needed. JS linters will remove unnecessary else statements by default. https://eslint.org/docs/latest/rules/no-else-return#rule-det... But never using it is crazy.

In a similar vein to how I just responded to the other person, maybe eventually we'll abstract `else` away so that it's use is hidden, and the abstraction ensures that it's only being used where we all collectively decide it can/should be used.

Re: Cognitive load is what matters

#403

Post by bambax »

Cognitive load is an important concept in aviation. It is linked to the number of tasks to run and the number of parameters to monitor, but it can be greatly reduced by training. Things you know inside and out don't seem to consume as much working memory.

So in software development there may be an argument to always structure projects the same way. Standards are good — even when they're bad! because one of their main benefit is familiarity.

Re: Cognitive load is what matters

#404

Post by cco »

cncjchsue7 wrote: post #398
safety1st wrote: post #377

Earlier quoted context omitted.

The approach that I am trialing with my team now, so far to good results, is as follows. * Our coding standards require that functions have a fairly low cyclomatic complexity. The goal is to ensure that we never have a a function which is really hard to understand. * We also require a properly descriptive header comment for each function and one of the main emphases in our code reviews is to evaluate the legibility a…

This sounds like hell to me. Not everything is complicated, most functions don't need comments, why require it? Just fix complexity when it arises. Don't mandate that you can't make any complexity.

What is a function supposed to do and why?

Re: Cognitive load is what matters

#405

Post by coding123 »

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

The approach that I am trialing with my team now, so far to good results, is as follows. * Our coding standards require that functions have a fairly low cyclomatic complexity. The goal is to ensure that we never have a a function which is really hard to understand. * We also require a properly descriptive header comment for each function and one of the main emphases in our code reviews is to evaluate the legibility a…

[dead]

Re: Cognitive load is what matters

#406

Post by hakunin »

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

The approach that I am trialing with my team now, so far to good results, is as follows. * Our coding standards require that functions have a fairly low cyclomatic complexity. The goal is to ensure that we never have a a function which is really hard to understand. * We also require a properly descriptive header comment for each function and one of the main emphases in our code reviews is to evaluate the legibility a…

I found this type of approach (where you try to meet subjective readability goals with objective/statistical metrics) to not produce clear code in practice. Instead, I suggest this one weird trick: if your colleagues are confused in code review, then rewrite and comment the code until they aren't confused anymore. Don't just explain it to them ad-hoc, make the code+comments become the explanation. There is no better linter than subjective reading by your colleagues. Nothing else works nearly as well. Optimize to your team's understanding, that's it. Somehow, this tends to keep working great even as the team changes.

Re: Cognitive load is what matters

#407

Post by bornfreddy »

cncjchsue7 wrote: post #398
safety1st wrote: post #377

Earlier quoted context omitted.

The approach that I am trialing with my team now, so far to good results, is as follows. * Our coding standards require that functions have a fairly low cyclomatic complexity. The goal is to ensure that we never have a a function which is really hard to understand. * We also require a properly descriptive header comment for each function and one of the main emphases in our code reviews is to evaluate the legibility a…

This sounds like hell to me. Not everything is complicated, most functions don't need comments, why require it? Just fix complexity when it arises. Don't mandate that you can't make any complexity.

Agreed. If you need a comment to tell you what the function does, you should think deep about naming, and if this fails, consider if this is the correct abstraction. Comments are a way to kick the can down the road - "I was unable to make this code clear enough, so here is the hint to help you".

Edit: sometimes the comments are the best of all evils, and you should use them to explain the constraints that led to this code - they just shouldn't be mandatory.

Re: Cognitive load is what matters

#408

Post by teiferer »

hakunin wrote: post #359
dlivingston wrote: post #337

Earlier quoted context omitted.

Can you expand on this?

Not the commenter, but also had experience with making music and writing software. I think the same applies to any creative endeavor. It’s super hard to consume what you produce as “someone else” (I.e. read what you write, listen to what you compose with fresh perspective). Usually it takes time to forget and disassociate from your work, because you get too used to it while producing it. Coming back to it another day…

> If you can train yourself to read your own code with fresh eyes almost as soon as you write it, you’d be unlocking a powerful shortcut, a cheat code to life.

This is really a key takeaway here: Always keep your audience in mind. When programming, you have two audiences: the machine executing the code, and fellow programmers maintaining the code. Both are important, but the latter is often neglected and is what the article is about. Optimize for your human audience. What will make it easier for the next person to understand this? Do that.

Like public speaking or writing an article. A great talk or a article happen when the speaker/author knew exactly how the audience would perceive them.

Re: Cognitive load is what matters

#409

Post by schnatterer »

> business logic and http status codes Why hold this custom mapping in our working memory? It's better to abstract away your business details from the HTTP transfer protocol, and return self-descriptive codes directly in the response body: { "code": "jwt_has_expired" }

While the logic behind it sounds reasonable, REST does the exact opposite with the same goal: simplicity, easy to learn, i.e. reduce mental load. I know there are other reasons for REST/SOAP/Graphql, etc. Still makes mental load a somewhat subjective matter to me.

Re: Cognitive load is what matters

#410

Post by hakunin »

teiferer wrote: post #408
hakunin wrote: post #359

Earlier quoted context omitted.

Not the commenter, but also had experience with making music and writing software. I think the same applies to any creative endeavor. It’s super hard to consume what you produce as “someone else” (I.e. read what you write, listen to what you compose with fresh perspective). Usually it takes time to forget and disassociate from your work, because you get too used to it while producing it. Coming back to it another day…

> If you can train yourself to read your own code with fresh eyes almost as soon as you write it, you’d be unlocking a powerful shortcut, a cheat code to life. This is really a key takeaway here: Always keep your audience in mind. When programming, you have two audiences: the machine executing the code, and fellow programmers maintaining the code. Both are important, but the latter is often neglected and is what the…

Agreed, I wrote more in depth about it a few years ago: https://max.engineer/maintainable-code
Post reply on HN