Live data from Hacker News

Cognitive load is what matters

github.com

511–520 of 552 posts

Re: Cognitive load is what matters

#511

Don’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.…

It hurts because it's true

The amount of staffs at my place who build pointlessly complex bullshit that doesn't actually do anything different is too damn high

Re: Cognitive load is what matters

#512

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 yo…

Also, apache ignores the content body and returns an empty string with several classes of error codes, so using 200 is the only reliable way when you want to get that custom error message to the user.

Re: Cognitive load is what matters

#513
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 actually think this is antithetical to the philosophy. Cyclometic complexity is very much not the same as "is this code difficult to understand".

Arbitrary structure rules like "do_thing_a(); do_thing_b(); do_thing_c();" also is not unless you can explain how this helps make it easier to understand compared to say, one big function with "// DO THING A" comments.

Re: Cognitive load is what matters

#514

I 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. W…

This is what I mean by "organizational problem". I understand that sometimes -- in fact most of the times -- you need to onboard mediocre programmers. But on the other hand, it's really great when you don't have to.

Re: Cognitive load is what matters

#515
post #110

Earlier quoted context omitted.

Mort is the pragmatist, Einstein is the perfectionist, and Elvis is... let's be honest, Elvis is basically cancer to a project. I guess maybe a small dose of Elvis can help motivate? I see the ideal as a combination of Mort and Einstein that want to keep it simple enough that it can be delivered (less abstraction, distilled requirements) while ensuring the code is sufficiently correct (not necessarily "elegant" mind…

> Elvis is basically cancer to a project. I guess maybe a small dose of Elvis can help motivate? Sometimes teams are quite stuck in their ways because they don’t have the capacity or desire to explore anything new. For example, an Elvis would probably introduce containers which would eliminate a class of dependency and runtime environment related issues, alongside allowing CI to become easier and simpler, even though…

Elvii often face a lot of criticism when Big New Ideas are overkill or they don’t work. They often get forgotten when the idea becomes standard issue and Mortified. The most pragmatic ideas today were Highly Risky and Unproved 10 years ago.

Re: Cognitive load is what matters

#516
post #372

Earlier quoted context omitted.

> 2. No visitor pattern. (See grug oriented development) This one is my particular pet-peeve. But I often think that the reason is because I suck. I'm going to read "grug". I also hate one-liner functions.

The real geniuses of our times can convert complexity into simplicity. The subgeniuses use complexity to flex over the common developer. Sometimes things need to be complex -- well that's okay. The real trick is to not put complexity into places it doesn't belong.

Complexity has to live somewhere. The genius is in putting in places that make things manageable, I guess.

https://ferd.ca/complexity-has-to-live-somewhere.html

Re: Cognitive load is what matters

#517
Cognitive load is super important and should be optimised for. We all should have as our primary objective the taming of complexity.

I was surprised to find an anti-framework, anti-layering perspective here. The author makes good points: it’s costly to learn a framework, costly to break out of its established patterns, and costly when we tightly couple to a framework’s internals.

But the opposite is also true. Learning a framework may help speed up development overall, with developers leaning on previous work. Well designed frameworks make things easy to migrate, if they are expressive enough and well abstracted. Frameworks prevent bad and non-idiomatic design choices and make things clear to any new coder who is familiar with the framework. They prevent a lot of glue, bad abstractions, cleverness, and non-performant code.

Layering has an indirection cost which did not appeal to me at all as a less experienced developer, but I’ve learnt to appreciate a little layering because it helps make predictable where to look to find the source of a bug. I find it saves time because the system has predictable places for business logic, serialisation, data models, etc.

Re: Cognitive load is what matters

#519

Earlier quoted context omitted.

on the other hand, I'd love to read an argument that persuades me that determinism doesn't matter in this case because I can't form any mental model that makes determinism-ed-ness a non factor in my decision making. of course, this comes with a disclaimer that I have no experience as a vibe coder lol

Real-world code bases are already far too large for any one programmer to internalize. They might as well be uninspectable. This problem isn't going to get anything but worse in the years to come. Incremental improvements in languages and methodologies won't suffice; future systems will simply have to be designed differently. They will be based on very high-level descriptions that can be used to synthesize tests that…

I suspect that some sort of AI will progress to some point of usefulness, the fact that it can do as much as it can right now should count for something. On the other hand, these llms seem to still go off into the weeds time and again, and from what I read of folks experiences, I can't drop the deterministic mindset as easy as folks like you can. Still, it doesn't matter, like you say these things are here and everyones throwing time and money at them, so hopefully my concerns are overblown and unfounded.

Re: Cognitive load is what matters

#520

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…

> one would have to look up what "isSecure" means, while "(condition4 && !condition5)" would have shown it at once You would feel the need to look up a variable called isSecure , but would not need to look up condition4 or condition5 ? I think the point TFA was making is that one could read isSecure and assume what kind of implementation to expect, whereas with condition4 I wouldn't even know what to look for, or I'd…

This is a very popular pattern in python where you'd introduce _variable before the evalution so:

if (user.id # you'd do

_user_has_access = (user.id # or even walrus

if _user_has_access := (user.id One of my coworkers really liked this pattern and his code was always so easy to read and to this day I'm carrying this torch!

Post reply on HN