←back to thread

Cognitive load is what matters

(github.com)
1455 points nromiun | 2 comments | 30 Aug 25 12:58 UTC | HN request time: 0s | source
Show context
exclipy ◴[30 Aug 25 20:51 UTC] No.45077894[source]▶
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.

replies(11): >>45077906 #>>45077954 #>>45078135 #>>45078497 #>>45078728 #>>45078760 #>>45078826 #>>45078970 #>>45079961 #>>45080019 #>>45082718 #
bsenftner ◴[30 Aug 25 20:58 UTC] No.45077954[source]▶
Which is why I consider DRY (Don't Repeat Yourself) to be an anti-rule until an application is fairly well understood and multiple versions exist. DO repeat yourself, and do not create some smart version of what you think the problem is before you're attempting the 3rd version. Version 1 is how you figure out the problem space, version 2 is how you figure out your solution as a maintainable dynamic thing within a changing tech landscape, and version 3 is when DRY is look at for the first time for that application.
replies(5): >>45078178 #>>45078299 #>>45078606 #>>45078696 #>>45079410 #
zahlman ◴[30 Aug 25 21:50 UTC] No.45078299[source]▶
DRY isn't about not reimplementing things; it's about not literally copying and pasting code. Which I have seen all the time, and which some might find easier now but will definitely make the system harder to change (correctly) at some point later on.
replies(10): >>45078465 #>>45078493 #>>45078525 #>>45078789 #>>45078797 #>>45078961 #>>45079164 #>>45079325 #>>45079628 #>>45079966 #
1. ori_b ◴[31 Aug 25 00:43 UTC] No.45079325{3}[source]▶
Not copy pasting code also makes it harder to change the system correctly at some point later on, because you transformed a local decision ("does this code do what the caller needs?") onto a global one ("does this code do what any possible caller needs, including across code maintained by other teams?")

There's no one rule. It takes experience and taste to make good guesses, and you'll often be wrong even so.

replies(1): >>45081240 #
2. n4r9 ◴[31 Aug 25 07:44 UTC] No.45081240[source]▶
It depends greatly on the situation. If you have five different methods for fetching WidgetInfo from the database and a requirement comes in to add TextProperty to Widget in all views, you're more likely to accidentally miss one of the places that needed a change.

Likewise if someone notices a bug in the method, you then have to go through and figure out which copies have the same bug, and fix each one, and QA test each one separately.

The proper approach is to make a judgement call based on how naturally generic the method is, and whether or not the existing use cases require custom behaviours of it (now or in the near future).