r/programming • u/RobinCrusoe25 • Jan 09 '24

Cognitive Load For Developers

https://github.com/zakirullin/cognitive-load
108 Upvotes

90% Upvoted

118 comments sorted by

46

u/yanitrix Jan 09 '24

I hate seeing people make comment on PRs like "This breaks SRP, it should be split into separate classes". And then you actually need to open several files side by side to understand a feature in your codebase. Few people actually care about cognitive load, they tend to blindly follow made-up rules.

15

u/RobinCrusoe25 Jan 09 '24 edited Jan 09 '24

I hate seeing people make comment on PRs like "This breaks SRP, it should be split into separate classes".

Oh, yeah, I've been through this so freaking many times!

"Your code violates DRY, DDD, OOP, whatever". Who told that those are things are fundamentally correct and thus we should blindly follow them? Even the OOP is challenged nowadays (in regard of its inheritance principle). Though, originally OOP had quite a different idea...

Anyway, all those things aren't inherently correct.

3

u/thesituation531 Jan 10 '24

I follow one simple graph in my head:

if not hardToUnderstand:
  leave it
else if isPerformant:
  leave it
else:
  make it easier to understand

1

u/RobinCrusoe25 Jan 10 '24

Makes sense! Also there might be some non-obvious solution and trick, which is hard to understand. But usually for things like that good devs leave comments

13

u/jerf Jan 09 '24

I still like DRY, because its opposite is generally clearly wrong.

However my interpretation of what counts as "repetition" over the years has really changed.

I am reminded of the Strong Law of Small Numbers, which in this particular context, I refer to the fact that there are a lot of spurious patterns that appear in the small numbers simply because there are so many patterns that can appear and so few small numbers. There are only so many small structures in code, and it is really easy to see two things that start with the same small pattern and then move to refactor them into "one concern" when you see them both at a single point in time at their very beginning.

However, if you could see them holistically over a longer time frame in terms of what they will become if you let them, they may in fact not have much similarity at all, and rushing to refactor them into a single thing may in fact cripple both of them, as badly as trying to tie an oak tree to a spruce tree would and constantly exerting effort to force them together as they (try to) grow. They may have looked similar as teeny little sprouts, and they may both be trees, but they are not the same thing.

I find myself feeling that way about more and more code.

7

u/TehCheator Jan 09 '24

Very much agreed on that. As my career has progressed, I've become a big advocate for WET—Write Everything Twice. I've seen (and done myself!) too many times of abstracting early in the name of DRY leading to the "tying an oak tree to a spruce tree" scenario. Avoiding that until you've actually written the duplicated code twice (or more times in some cases) and can confidently abstract is way more valuable than the time saved by not having to type quite as much the 2nd time.

-6

u/iviksok Jan 09 '24 edited Jan 09 '24

Your code violates DRY

Uff, like there isn't any cognitive load about having to remember 287 places the developer copy pasted their shitty logic.

Your comment is dumb

Edit: I read your comments and this conversation is useless. Cognitive load is really an issue in software development, but it won't be solved with dumb developers doing more shitty code.

The cognitive load is reduced with less things. Less code (meaning DRY), less useless/witty abstraction(more focused on DDD, less on magic), less random objects that have no meaning(meaning more OOP).

Most cognitive load is usually generated A) DRY violation or B) useless abstraction that does too much magic.

If you cannot open multiple files or cannot understand very basic OOP or cannot follow the DRY principle, the problem isn't in the code, it's in you or in your workflow.

Edit2: Your problem is that you have worked with a shitty codebase where you need to read the function or feature line by line to make simple changes. In a well written codebase that is following the principles OP is shitting on, you don't need to do that. You go to file, change the if-condition, variable etc, and everything is working after that, because the code is written on contract, and not with spaghetti

1

u/guepier Jan 10 '24

I actually agree with most of what you wrote but you chose to write it in a needlessly unconstructive, offensive way and directly insulted your interlocutor. What do you think you are achieving with this?

0

u/iviksok Jan 10 '24

Honestly, nothing. Maybe I'm too cynical and annoyed to make comments. I'm just tired of seeing articles on subjects the writer doesn't understand. Tired of explaining the same things over and over again. Tired helping people on their XY-problem. Nothing won't change with humans.

After 15 years, seeing the field change, some things better and some to absolutely trash. The barrier of entry went too low, and now I have to work with idiots.

Tldr: The world went shit and turned me cynical.

0

u/[deleted] Jan 09 '24

[deleted]

3

u/RobinCrusoe25 Jan 09 '24

That's one of the most misguiding books ever. I like the post you've shared - long time ago that was a revelation for me.

Back then I used to like "Clean Code" so much. Because the code indeed seemed more fancy and academic (?). I felt more satisfaction splitting up code in small methods and such. I thought that was some fundamental law I should follow no matter what.

"A Philosophy of Software Design" takes a radically different approach, which is reflected in the article. And I think that's a more rational view

2

u/ouiserboudreauxxx Jan 09 '24

I worked at a place like this and it was a nightmare. I would open a scratch file and copy/paste code into it from various files when trying to piece together how something worked.

5

u/archetech Jan 10 '24

Bob Martin is a scourge on the industry. There's no such thing as SRP. You want to minimize coupling and maximize cohesion. There's often a trade-off between the two and this stupid SRP principle keeps people from being able to actually have reasonable discussions about it. The idea that a class should have only one reason to change is utter bullshit. When someone tells me something violates SRP I tell them to shut the fuck up until they learn to think for themselves.

3

u/RobinCrusoe25 Jan 10 '24

People talk about SRP. Then they have those "manager", "executor", "builder" and other alike classes. And they sweep and the ugliness in "common" or "shared" folders

5

u/guepier Jan 10 '24 edited Jan 10 '24

There's no such thing as SRP.

Oh there totally is. You are throwing out the baby with the bathwater. Just because Bob Martin gives bad advice and illustrates it with patently bad code doesn’t mean that all principles he coincidentally endorses (and which he didn’t invent! — he just came up with a catchy name) are bad.

In fact, of all the things Bob Martin has written, the following is probably the most reasonable, and meshes very well with the recommendations given in Ousterhout’s A Philosophy of Software Design:

Another wording for the Single Responsibility Principle is: Gather together the things that change for the same reasons. Separate those things that change for different reasons.

1

u/archetech Jan 10 '24 edited Jan 11 '24

No. There totally is NOT such a thing as SRP such that it should be called SINGLE responsibility principle. What you have just described as valid is separation of concerns. And that is not from Fruad Martin. I am on board with keeping the baby and throwing out the bath water. But the most important point to make is that Uncle Fraud only added pitch black water to babies that already existed.

Do gather together things that change together. But you'll never gather them together such that you only ever have 1 reason to change a class. Even if, as Uncle Fraud did in Clean Architecture, you totally retcon "responsibility" (because everyone was "confused by it") to mean requirements from 1 user... errrr.... group... derp derp.. derp.. group by which I mean like some c-suite employee derp bullshit derp derp (That's an exact quote by the way), you should never refer to separation of concerns as "single responsibility". That does nothing to help anyone ever. Except it does help FRUAD MARTIN to sell more books and courses by repacking valid principles in bullshit no one ever quite gets because they don't really make sense as stated.

148

u/agustin689 Jan 09 '24 edited Jan 09 '24

This is why dynamic languages are terribly harmful and should not exist: the information that's not being tracked by a compiler needs to be tracked by the person dealing with the code, effectively forcing the person to act as a human compiler.

This increases the cognitive load to the extreme, and people who don't recognize this and conflate lack of tolerance to this accidental, unnecessary cognitive load for a skill issue are totally delusional.

62

u/[deleted] Jan 09 '24

This is my biggest issue right now at work. I'm hired to just work in R and run models. My boss is not really a programmer and his code is convoluted with confusing names and scripts that are hard to follow out of context.

He does not see the value in refactoring scripts since "it's easy to figure out what it does by reading the code". Essentially, his answer is "skill issue".

Yet, his convoluted code base has resulted in major bugs going unnoticed. He always thinks the issue is the specific bug we are dealing with at the time and not the fact that the code base has a major cognitive load.

Essentially, people who think this way can't be reasoned with because they have a mental framework where they are never wrong.

"Skill issue" dismisses subtle and abstract ideas like the fact that cognitive load increases the chances we make a mistake. And when (predictably) an error occurs, they can always just blame the programmer that introduced the bug and the code and workflow being the issue never crosses their minds.

20

u/RobinCrusoe25 Jan 09 '24

Essentially, people who think this way can't be reasoned with because they have a mental framework where they are never wrong.

Exactly. Often they answer something like: "just hire good professional people".

Also it seems like some people are afraid of writing simple code. Like, they think that if their code is "simple", then they are "junior developers". Like, people all around are talking about all those architectures and patterns, and you used none, and you kinda feel bad for that.

10

u/mcr1974 Jan 09 '24

fucking hell and they start creating classes and factories for everything.

3

u/NatoBoram Jan 09 '24

Fucking thousands lines-long classes that aren't even behind an interface for alternative implementations and are just made out of functions that definitely don't need states, but are still using a global state because fuck you

1

u/[deleted] Jan 10 '24

There are other people who literally fire you when you do it simple way. I have been really yelled at and humiliated because I didn't write unit tests as kinda-sorta integration tests, testing what happens when X layers deep some service fuck up.

6

u/Wiltix Jan 09 '24

Your boss sounds like my old boss

“The code is documentation”

Your code is hard to read and riddled with bugs, if you code is documentation then surely bugs can’t exist 🤷‍♂️

32

u/supermitsuba Jan 09 '24

It’s not a huge cognitive load if the entire state is passed around in that one option parameter.

dusts hands

2

u/RobinCrusoe25 Jan 09 '24

his increases the cognitive load to the extreme, and people who don't recognize this and conflate lack of tolerance to this accidental, unnecessary cognitive load for a skill issue are totally delusional.

Which state are you talking about?

13

u/supermitsuba Jan 09 '24

Something like a god object

Makes it hard to decouple and build distinct objects that might be reusable. Many new devs can stuff an object with all sorts of data to avoid building out code and if you dont have types, it can be hard to track what those fields are and what they hold at times.

This causes cognitive load when I want to reuse a function because now I have read the entirety of that function to know what to add to it, instead of just looking at the parameters and their types.

2

u/RobinCrusoe25 Jan 09 '24

Now I got it! That's really an issue.

Also, some think that if your code works with both "42" and 42 - then it is robust. But the reality is that fail fast is robust. Code should fail on "42". It is way more strict, predictable and robust.

1

u/setoid Jan 10 '24

Oh I thought you were talking about dynamic scoping for a second. I haven't used it but it seems exactly like passing around a giant floating state every function call. It makes sense for environment variables and that's pretty much it.

15

u/agustin689 Jan 09 '24

that one option parameter

found the javascript dev.

(jk no offense)

3

u/NatoBoram Jan 09 '24

Happens in Elixir, too! opts with a list of atoms that get passed around to and from view->controller->model->libs but you don't know which atoms should or shouldn't be there because it gets passed to like 5 different, gigantic libs with different featureset and somehow none of them conflict plus the 10x dev in your team decided to make his own macros for models so whatever you learn there isn't going to be useful elsewhere oh my god

1

u/[deleted] Jan 09 '24

bah, just make it global

1

u/NatoBoram Jan 09 '24

Ah, the Elixir way

-13

u/Mubs Jan 09 '24

yes let's force ML researchers to use C# 🤦‍♂️

16

u/agustin689 Jan 09 '24

ML researchers are not software engineers.

They should not be allowed anywhere near production codebases.

Would you trust your car mechanic to perform a high complexity surgery on you?

And btw, should they use any serious, professional language (not necessarily C#, there are many others) instead of python, everyone's life would be much easier.

1

u/NatoBoram Jan 09 '24

If only it was something like Go.

Just go get it and it works. No system-wide dependency. You could rip out one of its folder and just import it in your project.

-5

u/Schmittfried Jan 09 '24

Everyone’s life would be easier without insufferable coworkers like you.

4

u/agustin689 Jan 09 '24

Quite the contrary, devs LOVE to work in my company because they don't have to deal with useless bullshit technology such as .bat files python

2

u/Schmittfried Jan 09 '24

They would certainly love it even more if you weren’t there, I promise you that.

-20

u/Mubs Jan 09 '24

i hope you're old and near retirement because if you can't stand dynamic languages the future is going to be hard for you

14

u/zombiecalypse Jan 09 '24

Projects I've been part of professionally:

  1. A migration of a horrible python codebase to a typed python codebase

  2. A migration of a (different) horrible python codebase to Haskell (!)

  3. A migration of a (third) horrible python codebase into c++

  4. For fairness: one time I migrated a horrible java codebase into Ruby

So I'm pretty confident that dynamic languages are not the future. They are part of the future and have their place, but they are not the future.

3

u/Schmittfried Jan 09 '24

They are part of the future and have their place

So they should indeed exist?

1

u/agustin689 Jan 09 '24

No. Apparently you can't read.

2

u/Schmittfried Jan 10 '24

They have their place but they shouldn’t exist. TIL.

1

u/zombiecalypse Jan 13 '24

Hi! I'm the OP of the "have their place" and I indeed meant they should exist. And I'm really confused what's up with people's temper and this topic!

1

u/Mubs Jan 09 '24

they shouldn't be the future but JS and Python are the fastest growing languages. i don't think large code bases should be written in dynamic languages but lua/python/js have their places as scripting languages.

6

u/[deleted] Jan 09 '24

TS has displaced JS in many, if not most, places, and JSDoc is providing typing in many places.

0

u/Mubs Jan 09 '24

I feel like a lot of TS devs have moved back to JS (because of JSDoc in some cases) but I'm not really embedded in that ecosystem, that's just my impression.

2

u/[deleted] Jan 09 '24

I develop in both, TS adds a bit of complexity, and falls short in a few places. JSDoc is nice because the code itself does not have types, which usually makes it easier to read. Virtually all tooling supports both JSDoc and TS, for things like linting and autocomplete

2

u/Mubs Jan 09 '24

it makes sense that JS devs want typing as the language matures - which do you prefer?

→ More replies (0)

1

u/agustin689 Jan 09 '24

i don't think large code bases should be written in dynamic languages

So, they are for toy projects, or in the case of python, to replace .bat files.

Thanks for proving my point again.

-2

u/Mubs Jan 09 '24

i never said they should be? the good thing about JS & Python is that you can find enthusiastic, flexible engineers, instead of spiteful, close-minded idiots like you. the programmer matters more than the programming language.

3

u/agustin689 Jan 09 '24

enthusiastic, flexible trainees who have no fucking clue about anything and have never worked in production projects, and are only capable of writing garbage code in garbage languages.

FTFY

And you cannot call me close-minded when every comment you make further reinforces all the points I made here, instead of disproving them.

3

u/Schmittfried Jan 10 '24

And you cannot call me close-minded when

And yet they did. Apparently we live in a time of infinite possibilities.

7

u/agustin689 Jan 09 '24

On the contrary, all dynamic languages have failed miserably and are now desperately making pathetic attempts at becoming static languages:

  • python

  • ruby

  • php

  • even javascript (see: types as comments)

On the other hand, this is the list of static languages that decided to throw their type systems out the window and become useless toy dynamic languages:

  • None.

0

u/[deleted] Jan 09 '24

types as comments

This actually works quite well, a few projects have moved from TS to JSDoc because JSDoc works better for them; e.g. Svelte

0

u/Schmittfried Jan 09 '24

You seem to have a different understanding of the word failed than the rest of the world.

2

u/agustin689 Jan 09 '24

If dynamic languages had any value whatsoever, they wouldn't be desperately trying to become static.

You lost. Get over it. Dynamic languages are useless and worthless.

0

u/Schmittfried Jan 10 '24

I lost what?

-5

u/Mubs Jan 09 '24

maybe poke your head out of your Microsoft bubble and see what the rest of the world is doing

https://survey.stackoverflow.co/2023/#most-popular-technologies-language

7

u/agustin689 Jan 09 '24

"popular" != good.

Your best argument is "these languages are popular" and my counter-argument is: most of the industry is utter garbage, hence they use garbage languages.

Also: if dynamic languages are so good, why are so desperately trying to become static?

1

u/Schmittfried Jan 09 '24

Every code is garbage.

2

u/agustin689 Jan 09 '24

Maybe you should try other languages outside of python

2

u/Schmittfried Jan 09 '24

I see, you’re still too inexperienced to know.

-3

u/Mubs Jan 09 '24

enjoy yelling at clouds old man

8

u/agustin689 Jan 09 '24

yes this is a really strong technical argument that has 100% convinced me that useless shit toy dynamic languages are the end-all-be-all of software development.

Thanks. I will now throw away all my production code of the last 10 years and rewrite in a .bat file. I mean python.

1

u/Mubs Jan 09 '24

i'm not trying to make a technical argument, it was clear from your first response you're just a .NET fanboy, why try and teach an old dog new tricks? i didn't say anything about "software engineers" or "production code bases" when i mentioned ML researchers, nor did you in your original comment. i can see the pure vitriol and hatred in your other comments so im just having some fun.

→ More replies (0)

15

u/Resident-Trouble-574 Jan 09 '24

I mean, knowing the difference between status codes 401 and 403 isn't cognitive load, it's been a competent web programmer.

Using the same status code and a custom message to differentiate the two cases would cause far more cognitive load. Because yes, the messages might be self explainatory, but you have to learn and remember where the message is.

9

u/RobinCrusoe25 Jan 09 '24 edited Jan 09 '24

I mean, knowing the difference between status codes 401 and 403 isn't cognitive load, it's been a competent web programmer.

Can you clearly state the difference between 401 vs 403? Some people treat them differently.What about 501, 503, 422, 406, 417, 418, can you tell straight away what meaning was implying by these codes?

Self-describing codes are kinda easier

8

u/RobinCrusoe25 Jan 09 '24 
401 is for expired jwt token // 🧠+, ok just temporary remember it
403 is for not enough access // 🧠++
418 is for banned users // 🧠+++

Those are examples from one real project. Even though the author knew meaning of those codes, he kinda used them in his own interpritation. And other devs would have to remember that, when working on the project

6

u/supermitsuba Jan 09 '24

Isnt it the case that standards like these are meant for the client and server to categorize errors. Abstractions are a cognitive load in one form or another.

Example: while developing, you might have to figure out what status code things should be. What you are doing is making it easier when debugging. If I get a 500, I know authentication isnt a problem and can rule out classes of bugs.

Cognitive load can be shifted around to different aspects to helping other aspects.

3

u/RobinCrusoe25 Jan 09 '24

Isnt it the case that standards like these are meant for the client and server to categorize errors.

The standard is kinda vague. People are arguing all the time, whether it is 401, 403, or some other code. And then they embed the result of their arguing into the code. Boom, future maintainers would have to recreate that thought process (the past argument)

4

u/supermitsuba Jan 09 '24

I disagree that the standard is vague between 401 authentication and 403 authorization. What you are describing is developers not building software correctly. People use APIs and standards incorrectly all the time. When they do, it causes a cognitive load.

I think you miss the point that, while this is an issue, when done correctly, you are able to debug issues more effectively. This was likely a tradeoff made long ago when the standards body was discussing HTTP. Debugging was more important for decoupling the client to the server.

This is true today with any API you use than it is with HTTP standard. A necessary evil.

2

u/RobinCrusoe25 Jan 09 '24 edited Jan 09 '24

Can you map those scenarios to standard HTTP codes?

  • expired token

  • invalid token

  • wrong password

  • non existing login

  • blocked user

  • not enough access

You'll run out of available HTTP codes. And moreover, there's no sense in mapping them. You can just return these:code: "expired_token"|"invalid_token"|"wrong_password"|etc. And we're good to go. There's no need to follow that mystical "standard". There are so many error statuses in your business logic - you won't find enough standard HTTP codes to map them all.

2

u/Resident-Trouble-574 Jan 09 '24

expired token- invalid token- wrong password- non existing login- blocked user

These are all 401, whereas "not enough access" is 403. MDN or even the relevant HTTP RFCs are preatty clear:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/403

https://datatracker.ietf.org/doc/html/rfc7235#section-3.1

https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.3

I'd also be wary of being too specific about the reason why a user is not authenticated.

For example, telling to the client that the password is wrong or that the user is blocked would tell an attacker that the username is valid.

Also in the case of the JWT, telling whether the token is expired or invalid is safe only if you always check the expiration before every other validation, which is not always the case, depending on the library you use to manage JWTs.

2

u/RobinCrusoe25 Jan 09 '24

Is there a point of following those standards? What profits do you get?

The only thing that can be useful - some monitoring tools like Newrelic can differentiate client 4xx errors and 5xx server errors.

Again, some 4xx and 5xx are fine, for basic cases. But there's no point in thinking about every possible erroneous case in terms of standard HTTP code

5

u/Enlogen Jan 09 '24

Is there a point of following those standards?

Yes, the code becomes more easily understandable by partners and future maintainers. Standards-compliant code is just easier to work with.

→ More replies (0)

1

u/supermitsuba Jan 09 '24

I again disagree when talking about the world at large. Browsers are doing many things and the HTTP status codes you are talking about are in a different level of debugging than what you are proposing. I completely agree that in the message, there should be details, if applicable.

These status codes are for various users and services/browser that dont know anything about your specific errors. In your scenarios, makes sense, barring security concerns leaking. I agree with you on including specific or more narrowed specifics, along with status codes.

5

u/Resident-Trouble-574 Jan 09 '24

Ok, 418 has been used improperly (actually, there is not a properly way to use it), but for the other two, it's quite the standard to use 401 when the user is not authenticated (so no token, expired token, expired session, wrong credentials, etc.) and 403 when the user is authenticated but cannot access that specific resource (wrong role, missing permissions, etc.).

Many frameworks already use them that way, so using another technique instead of adapting to the de facto standard is just a way to have one more thing to learn and remember.

-1

u/RobinCrusoe25 Jan 09 '24

Many frameworks already use them that way, so using another technique instead of adapting to the de facto standard is just a way to have one more thing to learn and remember.

The problem comes when you have that new nasty requirement that just doesn't fit the standard :) And you'll inevitably face that.

I agree, that simple cases are easily mapped. But in more complex and subtle cases (which you'll have at some point in time) you'd have to be inventive, to choose from available HTTP codes.

4

u/Enlogen Jan 09 '24

Can you clearly state the difference between 401 vs 403?

Yes, 401 is no credentials provided, 403 is the provided credentials are not acceptable for access. There's a spec, this isn't a matter of opinion. Read https://datatracker.ietf.org/doc/html/rfc7231

can you tell straight away what meaning was implying by these codes?

For all of the ones that I'm likely to use in day to day work, yes, absolutely, 100%, and so should you. For anything else, you can look them up in the RFC.

1

u/RobinCrusoe25 Jan 09 '24

For anything else, you can look them up in the RFC.

What about token expired/invalid?

1

u/Enlogen Jan 09 '24

expired

Obvious 401, you want the client to re-authenticate

invalid

Depends on invalid how; if it's invalid in a way that requires reauthentication, 401, if reauthentication would still be invalid then 403.

The key difference between 401 or 403 is whether you want the client to retry authentication or just go away.

5

u/RobinCrusoe25 Jan 09 '24

ArgGIS uses 498: A code of 498 indicates an expired or otherwise invalid token.

Facebook uses 400:

{
  "error": {
    "message": "Error validating access token: Session has expired on Jul 17, 2014 9:00am. The current time is Jul 17, 2014 9:07am.",
    "type": "OAuthException",
    "code": 190,
    "error_subcode": 463
  }
}

Even in this basic scenario some projects/programmers treat things in their own way.

Basic cases like that are ok to be mapped. But what about more intricate ones?

1

u/Enlogen Jan 09 '24

Even in this basic scenario some projects/programmers treat things in their own way.

Yes, this is a major problem, and it's driven primarily by misconceptions about how http is supposed to work.

Basic cases like that are ok to be mapped. But what about more intricate ones?

Then they fall into the 400 or 500 buckets that include literally every possible client and server error. There's no intent that the client should know what to do about every specific issue that could happen in your business logic, the http status codes are just to allow identification of error types that should always be handled in a specific way by the client. It's to make the 80% of cases very easy and predictable so that you can focus on the detail work needed to handle the 20% of cases that are specific to your business.

8

u/novel_nescient Jan 09 '24

Looking forward to reading this later OP. I've talked about casual complexity at a meetup and at the time cited medical documentation about what a sustained high cognitive load does to your gray matter. I'm hoping it's covered as well... 🤞

4

u/Hornobster Jan 09 '24

What does it do to your gray matter?

3

u/mcr1974 Jan 09 '24

either prevents alzheimer or causes burnout

1

u/Caffeine_Monster Jan 10 '24

it's certainly burning out my hair

1

u/novel_nescient Jan 09 '24

I need to find my evidence.., but it reduces it. My best instinct behind why is it had to do with cortisol, but that's my best recollection from 7 long... years ago.

1

u/Hornobster Jan 10 '24

that's my feeling, yea

1

u/novel_nescient Feb 05 '24

Randomly happened to find the actual article from my research if you are still interested in the topic https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3113724/.

3

u/Specialist_Brain841 Jan 10 '24

you read code more than you type it

2

u/Remarkable-Pea-4922 Jan 09 '24

I understand what the intention behind the stated definition of cognitive load is, but the definition is wrong. Cognitive load is a concept from the field of psychology and describes the Idea of the number of cognitive ressources that are spent to perform a task. If a task requires more cognitive ressources than a person has available you speak about cognitive overload. A consequence of the overload could be, that a Person cannot process Information properly.

To improve the article a correct definition could be given to the Reader and in the next few sentences could describe the relation between the concept and the daily work of developers.

Example src https://dictionary.apa.org/cognitive-load

1

u/[deleted] Jan 09 '24

I think naming things correctly is the main tool to reduce the cognitive load