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

131–140 of 552 posts

Re: Cognitive load is what matters

#131

Post by KronisLV »

rapind wrote: post #110
noen wrote: post #18

This article reminds me of my early days at Microsoft. I spent 8 years in the Developer Division (DevDiv). Microsoft had three personas for software engineers that were eventually retired for a much more complex persona framework called people in context (the irony in relation to this article isn’t lost on me). But those original personas still stick with me and have been incredibly valuable in my career to understan…

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 previously using SCP and Jenkins and deploying things into Tomcat mostly worked. Suddenly even the front end components can be containers, as can be testing and development databases, everyone can easily have the correct version locally and so on.

An unchecked Elvis will eventually introduce Kubernetes in the small shop to possibly messy results, though.

Re: Cognitive load is what matters

#132

Post by pessimizer »

makeitdouble wrote: post #123
gherkinnn wrote: post #120

Earlier quoted context omitted.

Mort is happy with an if soup. Amanda sees what the if soup ought to do and replaces it with a simple state machine and fixes two bugs along the way.

Wouldn't refactoring the if soup into an algorithmically elegant solution what the Einstein does ?

Elegant is usually the opposite of maintainable. Reading elegant code is like reading a book of riddles (which is one of the reasons we enjoy it.)

Re: Cognitive load is what matters

#133

Post by flappyeagle »

darkstarsys wrote: post #70
darkstarsys wrote: post #69

Earlier quoted context omitted.

Clearly they were missing Amanda, the engineer who's had to review others' terrible code (and her own) for 20 years, and has learned the hard way to keep it simple. She knows she's writing code mostly for people to read, not computers. Give me a small team of Amandas any day.

And as a manager/CTO, the way to do this is to give the devs time to think about what they're doing, and reward implementation clarity (though it's its own reward for Amandas).

The way to do this is to chew people out when they let their own sources get in the way of doing a good job

Re: Cognitive load is what matters

#134

Post by AnimalMuppet »

api wrote: post #20
Buttons840 wrote: post #4

I'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 pile of if statements is a direct model of business deal making, which is literally a pile of if statements. Sales contracts with weird conditions and odd packaging and contingencies? Pile of if statements. The other great model for business logic is a spreadsheet, which is well modeled by SQL which is a superset of spreadsheet functionality. So piles of if’s and SQL. Yeah. Elegant functional or OOP models are usua…

But even with OOP... Virtual functions take over the pile of ifs, and so the ifs move to where you instantiate the class that has the virtual functions. (There is some improvement, though - one class can have many virtual functions, so you can replace all the ifs that ask the same question with one if that creates a class with all the right virtual functions. It gets messier if your class has to be virtual against more than one question.)

Re: Cognitive load is what matters

#135

Post by HumblyTossed »

Buttons840 wrote: post #4

I'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…

There are two things I hate more than anything else when coding - if statements and abstraction. If statements are bug magnets. Abstraction is a mental drain. My coding stile is to balance those two things in a way that makes the code as easy to read and extend as possible without relying on either too much and only just enough.

Re: Cognitive load is what matters

#136

Post by binoct »

makeitdouble wrote: post #123
gherkinnn wrote: post #120

Earlier quoted context omitted.

Mort is happy with an if soup. Amanda sees what the if soup ought to do and replaces it with a simple state machine and fixes two bugs along the way.

Wouldn't refactoring the if soup into an algorithmically elegant solution what the Einstein does ?

As I imagine it, Einstein would no be happy with fixing a couple bugs and making a state machine. Einstein would add a new unit test framework and implement a linear optimizer written with only lambdas to solve the problem and recommend replacing the web server with it as well. This is tongue in cheek but gets the idea across.

Re: Cognitive load is what matters

#137

Post by david_draco »

Unit and Integration testing is great for decreasing cognitive load too. When you are staring at an error stack trace of a complex code base, and go through mentally what could have played out to cause this, it's great to have confidence in components due to testing. Hypothesis/QuickCheck is allows dropping entire classes of worries.

Re: Cognitive load is what matters

#138

Post by weiliddat »

rowanG077 wrote: post #56

It's always interesting that many people who push the cognitive load argument also push for simpler languages. To me once I have learned a language well the features it has don't add to the cognitive load. they become basically second nature. It even has a great benefit, many things that are explicit in simple languages because there is no language support fall away in more complex languages. So more complex language…

Exactly, cognitive load is dynamic not static, and you can actually hold many more things in working memory than the oft-repeated 3-7 items (that's more if you're trying memorize and recall unrelated, novel items).

Once you commit a particular concept to long-term memory and it's not "leaky" (you have to think through the internal behavior/implementation details), then now you have more tools and ways to describe a collective bunch of lower-level concepts.

That's the same feeling programmers used to more powerful languages have to write less powerful languages — instead of using 1 concept to describe what you want, now you have to use multiple things. It's only easier if you've not grokked the concept.

Re: Cognitive load is what matters

#139

Post by pessimizer »

lxe wrote: post #27

Introducing intermediate variables is what I call "indirection". You're adding another step to someone reading the code. Let's take a recipe: Ingredients: large bowl 2 eggs 200 grams sugar 500 grams flour 1/2 tsp soda Steps: Crack the eggs into a bowl. Add sugar and whisk. Sift the flower. Add the soda. When following the instruction, you have to always refer back to the ingredients list and search for the quantity,…

Redundancy like that makes people like me feel that we missed something, and ruins forward progress. If you started "Crack 1 egg into the bowl." I'd move through it at light speed. When you say "Crack 2 eggs..." I think, "did I miss some ingredients, aren't there only two eggs?" and I rescan the entire ingredient list.

Then, still unsure, I go back and read the end of the sentence. "...into a large bowl."

Another large bowl? Wasn't there only one bowl? Was there another small bowl? Were the other eggs supposed to be in the small bowl? Is there another recipe listed separately where I'm supposed to crack the other egg (that might exist) into a small bowl? A single egg would only need a small bowl. Yes, there's probably another part of the recipe that is a sauce or filling or something that needs you to crack one egg into a small bowl. Let me reread everything on this webpage until I find something referred to that might be a necessary part of finishing this recipe, find the instructions to make that, then come back to this. Also, I have to reevaluate whether I even have enough eggs and bowls to make this recipe. I've read the entire page again, and I can't find what I'm missing. Maybe I'll google another, similar recipe, and they'll be a sauce or side that is mandatory for this dish that everybody already knows about but me, and it will be obvious. Ok, this is something similar, and it's served with some sort of a lemon sauce? I don't think I like lemon sauces. I'm not going to make this, I'm not even sure if I can. I hate trying to find recipes on the internet.

Re: Cognitive load is what matters

#140

Post by weiliddat »

Buttons840 wrote: post #28
marginalia_nu wrote: post #16

Earlier quoted context omitted.

I honestly think that's pretty close to optimal for a lot of places. With business software it's often not desirable to have large sweeping changes. You may need some small change to a rule or condition, but usually you want things to stay exactly the way they are. The model of having a circle of ancient greybeards in charge of carefully updating the sacred code to align with the business requirements, while it seems…

It does work for awhile, until one day: Project Manager: "Can we ship an order to multiple addresses?" Grey Beard: "No. We'd have to change thousands of random if-statements spread throughout the code." Project Manager: "How long do you think that would take?" Grey Beard: "2 years or more." Project Manager: "Okay, we will break you down--err, I mean, we'll need to break the task down. I'll schedule long meetings unti…

If Grey Beard doesn't relent

Project Manager: "Can we ship an order to multiple addresses? We need it in 2 weeks and Grey Beard didn't want to do it"

Eager Beaver: "Sure"

  if (order && items.length > 1 && ...) {  
    try {  
      const shipmentInformation = callNewModule(order, items, ...)  
      return shipmentInformation  
    } catch (err) {  
      // don't fail don't know if error is handled elsewhere  
      logger.error(err)  
    }  
  } else {  
    // old code by Grey Beard  
  }
Post reply on HN