The same principle applies within context engineering
Cognitive load is what matters
491–500 of 552 posts
Re: Cognitive load is what matters
#492> There is no “simplifying force” acting on the code base other than deliberate choices that you make. Simplifying takes effort, and people are too often in a hurry.
There is a simplifying force: the engineers on the project who care about long-term productivity. Work to simplify the code is rarely tracked or rewarded, which is a problem across our industry. Most codebases I've worked in had some large low-hanging-fruit for increasing team productivity, but it's hard to show the impact of that work so it never gets done.
We need an objective metric of codebase cognitive complexity. Then folks can take credit for making the number go down.
Re: Cognitive load is what matters
#493Hey, OP, stop bashing on functional languages..!
Re: Cognitive load is what matters
#494I'm probably one of the "smart developers" with quirks. I try to build abstractions. I'm both bothered and intrigued by the industry returning to, what I call, "pile-of-if-statements architecture". It's really easy to think it's simple, and it's really easy to think you understand, and it's really easy to close your assigned Jira tickets; so I understand why people like it. People get assigned a task, they look aroun…
> "A single order ships to a single address, keep it simple, build it, oh actually, a salesman promised a big customer, so now we need to make it so a single order can ship to multiple addresses"--you've heard something like this before, haven't you? I don't see the problem. Okay, so we need to support multiple addresses for orders. We can add a relationship table between the Orders and ShippingAddresses tables, fix…
> I don't see the problem. Okay, so we need to support multiple addresses for orders. We can add a relationship table between the Orders and ShippingAddresses tables
Which items ship to each of those locations and in which quantities?
What is the status of each of those sub-orders in the fulfillment process?
Should the orders actually ship to those addresses or should the cartons just be packed and marked for those locations for cross-docking and the shipments should be split across some number of regional DC's based on proximity to the final address?
Many things need to be updated in the DB schema+code. And if you think this isn't a very good example, it's a real life example of orders for large retailers.
Re: Cognitive load is what matters
#495The ability to create code that imposes low cognitive load on others not only is a rare and difficult skill to cultivate- it takes active effort and persistence to do even for someone who already has the ability and motivation. I think fundamentally the developer is computing a mental compression of the core ideas - distilling them to their essence - and then making sure that the code exposes only the minimum essenti…
This is also true of interface/UX/interaction design. Most developers are really skilled at maintaining a higher cognitive load than most, and the interfaces that work best for less technical people often frustrate developers, who want everything in front of them, visible, at all times because they intuitively know what’s important. Interfaces created by developers might click with other devs, but often bewilder less…
This was maybe a problem years ago, but I don't think its a pro lem these days. I see many more cases of the opposite problem, interfaces that are meant of technical users but are designed using modern mobile centric paradigms, over emphasizing negative space and progressive disclosure.
this is also a problem for tools designed for non-technical users for complex tasks that are performed frequently. your power users needs a powerful interface even if they are less technical.
Re: Cognitive load is what matters
#496Earlier quoted context omitted.
Visitors additionally allow you to decouple graph traversal from the processing. It is still needed even in the languages with pattern matching. There's also the question of exhaustiveness checking. With visitors, you can typically opt-in to either checking that you handle everything. Or use the default no-ops for anything that you're not interested in. So if you look at compilers for languages with pattern matching…
The example you posted is very interesting as it used both a visitor and ADTs. It seems the need for the Visitor comes from the generics in this case? Probably a Rust specific limitation. I don’t understand why you mention exhaustiveness though, it’s obviously easy have comprehensive or partial matching with ADT.
No. The code can be rewritten without visitors using iterators for traversal, for example). But it'll look badly.
Visitors in the linked example are real classic visitors. The code _within_ the visitor methods, of course, uses pattern matching, but the pattern itself is not materially different from C++.
Exhaustiveness checking for pattern matching is also "best effort" for complex matching.
Re: Cognitive load is what matters
#497I'm probably one of the "smart developers" with quirks. I try to build abstractions. I'm both bothered and intrigued by the industry returning to, what I call, "pile-of-if-statements architecture". It's really easy to think it's simple, and it's really easy to think you understand, and it's really easy to close your assigned Jira tickets; so I understand why people like it. People get assigned a task, they look aroun…
I like to make truth tables for understanding piles of ifs. Like there's 5 ifs with 5 different conditions - so I make 5 columns and 32 rows, and enumerate all the possible combinations of these 5 ifs and write what happens for each. And then what should happen. Of course, the disadvantage is the exponential growth. 20 ifs means a million cases (usually less because the conditions aren't independent, but still). Then…
Often you can check validity one time before everything else. 5 bools might only actually be valid in 7 possible combinations instead of 32. Convert in one place to a 7 element enum and handle with exhaustive switch statements everywhere else can sometimes be a lot cleaner.
Making invalid data unrepresentable simplifies so much code. It's not always possible but it is way underused. You can do some of it with object encapsulation too, but simple enums with exhaustive switch statements enforced by the compiler (so if it changes you have to go handle the new case everywhere) is often the better option.
Re: Cognitive load is what matters
#498Earlier quoted context omitted.
> 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…
In a sense, all of these coding practices -- whether restricting goto to loops and conditionals, which has broad acceptance these days, or avoiding else to "keep the happy left", or anything else in a coding style guide -- are just doing one thing: restricting the language to a smaller subset of itself.
And in general the primary benefit of such restriction is to reduce cognitive load. Scheme is easier than C++. The downside of such restriction is loss of expressiveness. Whether the net benefit is good depends on how these two things trade off. Experience and developer preference are inputs to that equation, which is why devs fight over coding guidelines. But I think it's helpful to boil it down in this way at a high level.
The ideal is smaller language where the expressiveness you've cut away is only rarely useful, and often error-prone.
Re: Cognitive load is what matters
#499Re: Cognitive load is what matters
#500Earlier quoted context omitted.
This is also true of interface/UX/interaction design. Most developers are really skilled at maintaining a higher cognitive load than most, and the interfaces that work best for less technical people often frustrate developers, who want everything in front of them, visible, at all times because they intuitively know what’s important. Interfaces created by developers might click with other devs, but often bewilder less…
This was maybe a problem years ago, but I don't think its a pro lem these days. I see many more cases of the opposite problem, interfaces that are meant of technical users but are designed using modern mobile centric paradigms, over emphasizing negative space and progressive disclosure. this is also a problem for tools designed for non-technical users for complex tasks that are performed frequently. your power users…
Those interfaces are not likely designed by interface designers — they’re either assembled by developers using framework libraries trying mimic things that ‘look designed,’ or “designed” by visual designers that have no more business designing interfaces than Wordpress plugin developers have designing your network architecture. Your first clue is your citing the ‘mobile first’ design— The first step in any serious interface design is researching who your users are, what they need, in what environment, and with what tools. Something being mobile-first is an implementation detail that has nothing to do with the core design. You don’t notice well-designed interfaces because if it’s properly designed, you concentrate on solving your problem and not the tool that’s solving it. If you’ve got primarily technical users and you’re not giving them technical tools, or you have a lot of power users and aren’t giving them power user tools, you probably didn’t do the thing that every subsequent decision in the design process should be based on: research the who, what, where, why, and when of the interface.
The problems you cite aren’t caused by bad design, but a lack of design, altogether.