Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cognitive load is what matters

github.com

Post reply on HN
Print view View original

341–350 of 552 posts

Re: Cognitive load is what matters

#341

Post by kyralis »

dahart wrote: post #190
rapind wrote: 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…

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.

Re: Cognitive load is what matters

#343

Post by ori_b »

zahlman wrote: post #290
bsenftner wrote: post #270

Earlier quoted context omitted.

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

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.

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.

Re: Cognitive load is what matters

#344

Post by citizenpaul »

Swizec wrote: post #251
citizenpaul wrote: post #197

Earlier quoted context omitted.

I'm not sure the author or most people that write these types of academic theory papers ever really see actual ball-of-mud-spaghetti code in real world scenarios. I think anyone that thinks mudball is OK because business is messy has never seen true mudball code. I've had to walk out of potential work because after looking at what they had I simply had to tell them I cannot help you, you need a team and probably at m…

> I think anyone that thinks mudball is OK because business is messy has never seen true mudball code. I’ve seen and created some pretty bad stuff. Point is not that it’s okay, but that that’s the job: managing, extending, and fixing the mess. Yes a perfect codebase would be great, but the code is not perfect and there’s a job to do. You’re not gonna rebuild all of San Francisco just to upgrade the plumbing on one st…

Sure but again you are referring to somewhat structured systems that went off the rails a bit. Thats not what I consider a mudball.

I've seen numerous places trying to hire someone to fix a 5-10 year mudball that has reached a point where progress is no longer possible without breaking something else which breaks something else and so on.

There is an endgame to the mudball and it does end in complete and total development stopping and systems that are constantly going offline and take weeks to get restarted. Most of the time the place will say: "Oh we've already had several consultants tell us the same thing" The same thing being the situation is hopeless and they are facing years of simply untangling the mess they made.

Usually the mudball is held together by a chain of increasingly shorter senior positions that keep jumping the sinking ship faster and faster. Finally they can no longer convince anyone sane to take on the ticking time bomb they have created and they turn to consultants.

Also my advice is often you should bring back person X that was at least familiar with the system at whatever salary they require. I am inevitably told that that person will literally not even take calls or emails from the company any more, every time. Thats how bad a real world mudball is.

Re: Cognitive load is what matters

#345

Post by maccard »

goalieca wrote: post #313
an0malous wrote: post #172

Earlier quoted context omitted.

“When you do things right, people won’t be sure you’ve done anything at all”

This is bad for promotions. You have to make grand efforts with impacts of saving things that clearly need saving.

There’s more than one way to get promoted. Being the common factor among projects that succeed is a really really good one, and IME it’s far more common to find people promoted after one successful project than it is to a “noisy Nancy” be promoted.

Re: Cognitive load is what matters

#346

Post by zakirullin »

YZF wrote: post #316
exclipy wrote: post #264

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.

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…

> I like the article but the people who need it won't understand it

That's true. One doesn't change his mindset just after reading. Even after some mentorship the results are far from satisfying. Engineers can completely agree with you on the topic, only to go and do just the opposite.

It seems like the hardest thing to do is to build a feedback loop - "what decisions I made in past -> what it led to". Usually that loop takes a few years to complete, and most people forget that their architecture decisions led to a disaster. Or they just disassociate themselves.

Re: Cognitive load is what matters

#347

Post by cm2012 »

BlarfMcFlarf wrote: post #325
cm2012 wrote: post #171

Earlier quoted context omitted.

Its kind of a common thing to say Myers-Briggs typing is useless because its pseudo-science. I dont think this is supported by the data in the way people think. For one, many studies of identical twins raised in separate households show they have the same personality type at a much higher rate than chance. Two, there are incredibly strong correlations in the data. In different surveys of 100k+ people, the highest ear…

You can pick any set of axis you feel like and get similar results. “Do you like X? Wow you are an X person!”. So yeah, technically better than horoscopes, more like a “warm” reading where you tell a person what they told you earlier. But it’s entirely unclear why these axis are the right ones over a million other possible ones, if these are particularly stable categories in time and context, or if the harm of encour…

It's good questions. Here's why this axis is the right one in my opinion:

1) As I mentioned, it has a lot of statistically significant correlations, including to all the variables of the Big 5. Example: Surveys show that % of the overall population that is each type (like INFJ) is very consistent across time and populations.

2) Beyond that, youre right, there are a lot of personality systems with pros and cons. But Myers-Briggs has by far the must supporting materials, tools, ease of use, and so on. I think its the quickest to make useful to the average person.

3) I've found it really helpful as a lens for self analysis in my own life.

Re: Cognitive load is what matters

#348

Post by cyberax »

bsenftner wrote: post #270
exclipy wrote: post #264

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.

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

DRY means something completely different. It means that there should be just one source of truth.

Example: you have a config defined as Java/Go classes/structures. You want to check that the config file has the correct syntax. Non-DRY strategy is to describe its structure in an XSD schema (ok, ok JSON schema) and then validate the config. So you end up with two sources of truth: the schema and Java/Go classes, they can drift apart and cause problems.

The DRY way is to generate the classes/structures that define the config from that schema.

Re: Cognitive load is what matters

#349

Post by alphazard »

zakirullin wrote: post #287
alphazard wrote: post #275

The bit about "smart developer quirks" looks suspiciously like the author only understands code that they have written, or is in a specific style that they recognize. That's not the biggest driver behind cognitive load. Reducing cognitive load comes from the code that you don't have to read. Boundaries between components with strong guarantees let you reason about a large amount of code without ever reading it. Makin…

Having a clear and minimalistic API doesn't mean that the underlying code is easy to understand. It's good when things just work and you can use an API, but most of the time you have to dig whatever is under the rug.

> Having a clear and minimalistic API doesn't mean that the underlying code is easy to understand.

Doesn't need to be. The API tells me what it does, hopefully there is a test suite to assure me. I can add to the test suite if I have a question, or want to lock in a behavior.

When it's a third party library, everyone assumes it's supposed to work? but when it's a system in the same repository, all of a sudden all bets are off, and you need to understand it fully to get anything done?

> It's good when things just work and you can use an API, but most of the time you have to dig whatever is under the rug.

If most changes require simultaneously changing multiple areas of the code, such that changing one system implies changing every other system with roughly equal probability, then it's not well designed.

I don't know what else to tell you. It's going to be hard to iterate or maintain that system, in part because it requires a high cognitive load. None of the code in such a system provides any cognitive leverage. You can't rule out, or infer behavior of a large amount of code, by reading a small amount.

If such a system is important, then part of the strategy has to be to improve the architecture.

Re: Cognitive load is what matters

#350

Post by ttz »

andix wrote: post #310
ttz wrote: post #307

Earlier quoted context omitted.

You can still design for evolution and follow best practices. That's actually IMO a hallmark of good software design. The issue is when the evolution is random and rife with special cases and rules that cannot be generalized... the unknown unknowns of reality, as you say. Then, you just gotta patch with if elses.

> The issue is when the evolution is random and rife with special cases and rules that cannot be generalized You’ve just described the universe. It’s full of randomness.

Thank you for this relevant insight.
Post reply on HN