I think this just describe why people procrastinate.
Cognitive load is what matters
481–490 of 552 posts
Re: Cognitive load is what matters
#482While I support the goal of article, reducing extraneous cognitive load, I think some of the comments, and the article are missing a key point about cognitive load — it depends on the existing mental model the reader/author/developer has about the whole thing. There is no universal truth to reducing cognitive load like reducing abstractions / not relying on frameworks. Reducing cognitive load doesn't happen in a vacu…
There's a chapter about mental models: https://github.com/zakirullin/cognitive-load?tab=readme-ov-f...
Yes, and I hope I made a point that it's not the right approach always.
> If you've internalized the mental models of the project into your long-term memory, you won't experience a high cognitive load ... If you keep the cognitive load low, people can contribute to your codebase within the first few hours of joining your company.
Yes, if you really are having new joiners often, and you expect them to be onboarded quickly. That happens for a specific segment of the software industry, not generally.
If you're working with the same people all the time, and it's the nth time someone made a mistake in a huge frontend JS codebase (pre-Angular/React) trying to wrangle with plain events and DOM state, a new framework (like React and co) that abstracts away events and DOM state management was perhaps the right choice.
This way of thinking and abstraction is so popular now that it's taken almost for granted by people who started learning programming for the web recently. For these people, using plain JS might be higher cognitive load, so
> Lots of cool architectures, fancy libraries and trendy technologies were used. In other words, the author had created a high cognitive load for us.
that's not a universal statement.
Do I personally believe there are better levels of abstraction, and simpler frameworks than React, Express, Django, Spring, Laravel, etc.? Yes, but if the developers you are hiring/teaching/working with are familiar with those, and it's working for them, then maybe that is the right choice to use.
The main statement I agree with in the article (apart from the goal of reducing cognitive load) comes much later, in
> So, why pay the price of high cognitive load for such a layered architecture, if it doesn't pay off in the future? Plus, in most cases, that future of replacing some core component never happens.
where the main problem is having the wrong reasons or wrong choice of architecture. It's not necessarily that abstraction/architecture is bad. I feel like the message of "you should keep it simple" is overemphasized in the rest of the article. Maybe that's in response to overengineering in the industry or the author's experience.
Re: Cognitive load is what matters
#483This 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.
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…
> Every rule can be used to argue anything.
This is true. However, very few people can clearly explain all the rules.
If they can, they have understood the system and are qualified.
Re: Cognitive load is what matters
#484Earlier 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…
> You can't win architecture arguments. I feel this in my soul. But I'm starting to understand this and accept it. Acceptance seem to lessen my frustration on discussing with architects that seemingly always take the opposite stance to me. There is no right or wrong, just always different trade offs depending on what rule or constraint you are prioritizing in your mind.
The problem with a lot of devs is trying to win arguments instead of coming to a consensus. What’s best for the team matters more than what’s best for the individual and every team is different.
Re: Cognitive load is what matters
#485I 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…
> programmers agree that simpler solutions...are preferred, but the disagreements start about which ones are simpler
Low ego wins.
1. Given: The quality of a codebase as a whole is greatly affected by its level of consistency + cohesiveness
2. Therefore: The best codebases are created by groups that either (1) internally have similar taste or (2) are comprised of low ego people willing to bend their will to the established conventions of the codebase.
Obviously, this comes with caveats. (Objectively bad patterns do exist.) But in general:
Low-ego → Following existing conventions → They become familiar → They seem simpler
Re: Cognitive load is what matters
#486Don’t bother with this if you want to get promoted. Others have discussed this in thread and are right. If you build beautiful, simplified abstractions, your skill will be taken for granted as these interfaces appear obvious once discovered (by virtue of their proximity to truth, incredibly difficult to create, easy to verify). If you are in even a reasonably large org, go the other way. Be an Architecture astronaut. Build complex, clever stuff that is deliberately high cognitive load. Get your bus-factor as close to one as possible. Go the other way only if your comp is directly tied to company performance.
Re: Cognitive load is what matters
#487Earlier quoted context omitted.
Your comment made me think Mort represents efficiency, Einstein represents quality, and Elvis represents risk. The ideal combination is difficult, and it changes over time. If anyone knew what the ideal combination was, companies would never fail. Risk can get something started, and lack of it can eventually kill software. In fact, I would argue the vast majority of software we’ve seen so far dies an eventual death d…
Mort might mean short-term efficiency, but those solutions are where technical debt and unmaintainable organically-grown complexity come from. That has its time and place, but it must be balanced to not doom anything but short-lived projects.
The only place I’ve seen technical debt and organic complexity come from in real life is from over-engineering (Einsteins over-engineer the code, and Elvises bring in too many dependencies) and, more importantly, from changing requirements (customers & PMs & management). The changing requirements is the bigger culprit most of the time, and that doesn’t reflect directly on programmers or programmer personalities. I’ve never seen efficiency arguments make the code unwieldy. If anything, the problem is that real life Morts sometimes under-engineer, and it takes some of the other types to build up a bit. I’ve seen over-engineering far more often than under-engineering. Anyway, Mort only means short-term efficiency if you make assumptions. It didn’t in the top comment, and it doesn’t have to, you can just as easily assume efficiency is long term and includes efficiency of maintainable code and efficiency of business processes. If you care about the business outcome, why would you jump to the conclusion that it’s short term thinking?
Re: Cognitive load is what matters
#488I 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…
> code with a high cognitive load keeps mediocre developers away.
That's true and it's a positive thing but the downstream consequences are often painful. We had a c/c++ project with complex memory management and heavy multithreadding, written that way because the superstar developer could handle the cognitive load and found the assignment intellectually challenging. That was great until they left for the next job.
We were left fighting a codebase with a big cognitive load, so we were desperately dependent on hiring more superstars just for routine maintenance. We eventually concluded that this wasn't a sustainable model and rewrote the system in plain old python. Much happier now.
Re: Cognitive load is what matters
#489Love it. Make code accessibility a first-class citizen. Turn the rule books and their principles into guidelines . A smart coder knows to follow rules. A master knows code is meant to be read and develops contextual awareness for when and why to break a rule, or augment it, as the case may be. So, reintroduce judgment and critical thinking in your coding practice. Develop an intuitive feel for the cognitive costs and…
> Make code accessibility a first-class citizen. This is a good article but the main thing that bugs me about it is that the author completely disregards germane overhead. Germane overhead is about recognition and practice and, at scale, it matters just as much. Intrinsic and extraneous overhead is about the information itself and how it’s presented. Germane overhead is about the receiver so in order to make code acc…
This is correct. To delve into a topic about cognitive load without talking about germane overhead disqualifies this article (i.e. similar to extraneous overhead in terms of effort but germane overhead is beneficial. Because it helps the coder's reading ability.)
The examples are good but every reader must not have the takeaway that every effortful code is bad (e.g. haskell is extremely hard to read at first but every developer swears it has very high intrinsic cognitive load)
Re: Cognitive load is what matters
#490I 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…
I prefer to have both single return and early return, like this: https://github.com/lelanthran/libds/blob/b5289f6437b30139d42...