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

461–470 of 552 posts

Re: Cognitive load is what matters

#461

Post by epolanski »

swat535 wrote: post #332
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 g…

There is no objective "perfect", because the "perfect" is in the eyes of the reader.

Also, people confuse familiar with simple, they tend to find things simple if they are familiar, even if they are complex (interwine a lot of different things).

Re: Cognitive load is what matters

#462

Post by davemp »

Cthulhu_ wrote: post #455
defanor wrote: post #422

I think most programmers agree that simpler solutions (generally matching "lower cognitive load") are preferred, but the disagreements start about which ones are simpler: often a lower cognitive load comes with approaches one is more used to, or familiar with; when the mental models one has match those in the code. For instance, the article itself suggests to use early/premature returns, while they are sometimes comp…

Likewise, some people prefer ternary statements for short checks; I want to agree because ternaries are one of the first things you learn after if/else/while/for, but at the same time... they're a shorthand, and shorthand is short but not necessarily more readable. For one-off things like value = condition ? a : b I don't mind much, but I will make an issue as soon as it spans more than one line or if it's nested.

I prefer it as long as there’s no side effects. You get tighter semantics which I think helps readability (and I trust compilers to be able to handle it optimally). I find the following format to be very nice:

    value = (condition)
      ? foo
      : bar;

Re: Cognitive load is what matters

#463

Post by neutronicus »

brucehoult wrote: post #440
defanor wrote: post #422

I think most programmers agree that simpler solutions (generally matching "lower cognitive load") are preferred, but the disagreements start about which ones are simpler: often a lower cognitive load comes with approaches one is more used to, or familiar with; when the mental models one has match those in the code. For instance, the article itself suggests to use early/premature returns, while they are sometimes comp…

> For instance, the article itself suggests to use early/premature returns I like premature returns and think they reduce complexity, but as exclipy writes (I think quoting Ousterhout) 'complexity is defined as "how difficult is it to make changes to it"'. If premature returns are the only premature exit your language has then they add complexity in that you can't then add code (in just one place) that is always exec…

An old C/C++ argument lol. The C people want their exit blocks, the C++ people want to write destructors.

As a C++ guy I'm on the early-return side of things, because it communicates quickly which fallible operations (don't) have fallbacks.

You see "return" you know there is no "else".

Also, as a code-formatting bonus, you can chain a bunch of fallible operations without indenting the code halfway across your monitor.

Re: Cognitive load is what matters

#464

Post by zakirullin »

defanor wrote: post #422

I think most programmers agree that simpler solutions (generally matching "lower cognitive load") are preferred, but the disagreements start about which ones are simpler: often a lower cognitive load comes with approaches one is more used to, or familiar with; when the mental models one has match those in the code. For instance, the article itself suggests to use early/premature returns, while they are sometimes comp…

Cognitive load depends on the mental models one has, yes.

> The problem is that familiarity is not the same as simplicity. They feel the same — that same ease of moving through a space without much mental effort — but for very different reasons. Every “clever” (read: “self-indulgent”) and non-idiomatic trick you use incurs a learning penalty for everyone else. Once they have done that learning, then they will find working with the code less difficult. So it is hard to recognise how to simplify code that you are already familiar with. This is why I try to get “the new kid” to critique the code before they get too institutionalised!

This was explored in the latter part of the article.

Re: Cognitive load is what matters

#465

Post by jama211 »

whilenot-dev wrote: post #281
jama211 wrote: post #235

Earlier quoted context omitted.

Mort is the only one who does their job from the perspective of the business owner.

I think implementing stuff correctly (Einstein) is sometimes more important than doing what you're told to do (Mort) - requirements don't always represent business interests.

It’s more important if your goal is an _actually good product_. Whether that’s the goal of the stakeholders is quite honestly up to them.

Re: Cognitive load is what matters

#466

Post by jama211 »

zmmmmm wrote: post #319
jama211 wrote: post #231

Earlier quoted context omitted.

I think this is somewhat dangerous, it can lead you to categorise people unfairly and permanently. Also, in my experience this has a critical flaw - the managers love morts in my experience, not Elvises. They don’t care about the technical details, so “fastest and fits the business outcome the most” is ideal. Also the actual solution is proper team leadership/management. If you have morts, make sure that code quality…

I agree with you and one of the most important ways is that it bakes in an assumption that people cant grow, learn and change. Life is all about learning, adapting and changing. Great leaders see the potential growth in people and are up for having hard conversations about how they can improve. Even if people do have these personality traits as life long attributes, that doesn't define them or prevent them from learn…

Well said!

Re: Cognitive load is what matters

#467

Post by Culonavirus »

shreddit wrote: post #441

Don't agree with "Business logic and HTTP status codes" tbh, because now i have to work with apis that do this: Statuscode: 200 { success: false, error: "..." }

I don't really care either way, it's not a big issue to me, but I can see why people might do that. I mean what if an api endpoint returns a 403 when the end user doesn't have access to that resource, but also 403 because you, the consumer/app doesn't have access to the "server" the api is running on? HTTP codes were originally intended as server status codes, not server application status codes. At least with 200 you know your request was processed on the server successfully.

Re: Cognitive load is what matters

#468

Post by mattmanser »

brucehoult wrote: post #440
defanor wrote: post #422

I think most programmers agree that simpler solutions (generally matching "lower cognitive load") are preferred, but the disagreements start about which ones are simpler: often a lower cognitive load comes with approaches one is more used to, or familiar with; when the mental models one has match those in the code. For instance, the article itself suggests to use early/premature returns, while they are sometimes comp…

> For instance, the article itself suggests to use early/premature returns I like premature returns and think they reduce complexity, but as exclipy writes (I think quoting Ousterhout) 'complexity is defined as "how difficult is it to make changes to it"'. If premature returns are the only premature exit your language has then they add complexity in that you can't then add code (in just one place) that is always exec…

Personally I wouldn't agree with this. I've adopted a pattern where I try to only ever return the success value at the end of a function. Early returns of success value don't feel clear to me and make the code hard to read. I think that sort of code should only be used if you need high performance. But for clarity, it hurts.

Instead I think you should generally only use early returns for errors or a null result, then they're fine. Ditto if you're doing a result pattern, and return a result object, as long as the early return is not the success result (return error or validation errors or whatever with the result object).

So I feel code like this is confusing:

    function CalculateStep(value) {
       if(!value) return //fine

       ///a bunch of code
   
       //this early return is bad
       if(value
The early return is easy to miss when scanning the code. This is much less confusing:

    function CalculateStep(value) {
       if(!value) return //fine

       ///a bunch of code
   
       let stepsResult : Step[]

       if(value
It makes the control flow much more obvious to me. Also, in the 2nd pattern, you can always have your cleanup code after the control block.

Re: Cognitive load is what matters

#469

Post by austin-cheney »

People can argue about this all day, but one thing is always crystal clear.

Simplicity comes from practice writing and refactoring large code thousands of times. People with limited or shallow experience may think they are good at this but only when they isolate themselves to known patterns of comfort or some giant framework. There is a lot of insecurity there.

Super experienced people, that is people with lots of practice writing large original applications, don’t think like the pretenders. Simplicity is built in like muscle memory. They just solve fucking problem and go drink a beer. There is no memorized pattern nonsense.

The super experienced developers see the pretenders for what they are while the pretenders either can’t see the distinction or just feel hostility at the deviation far outside a memorized convention.

Re: Cognitive load is what matters

#470

Post by ferguess_k »

brabel wrote: post #439
ferguess_k wrote: post #363

Earlier quoted context omitted.

I'm struggling with the amount of complexity. As an inexperienced SWE, I found it difficult to put everything into my head when the # of function calls (A) + # of source code files (B) to navigate reach N. In particular, if B >= 3 or A >= 3 -- because, B equals the number of screens I need to view all source code files without Command+Tab/Alt+Tab, and cognitive load increases when A increases, especially when some "p…

You should not need to read every line of code in every file and function to understand what’s going on to the level you need to solve a particular problem. You must make a decision to NOT look deeper at some point on any non- trivial code base. A good program with good names and comments in the appropriate places is what allows you to do exactly that more easily . When you see sort(usernames) in the middle of a func…

The problem is, most of us are working in business logic, and I have never been in a company (have been to 5) where you don't have to look into the details. Not only did I need to look at the details, I also needed to read the comments to understand why there is a +0.024 in the code.

This is why I want to get into system programming. At least less business logic. They are still going to be complicated, but I feel it's a lot nicer to, e.g. go from the bottom of the process struct than the bottom of some half-ass business stakeholder!

Post reply on HN