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

541–550 of 552 posts

Re: Cognitive load is what matters

#541

Post by chipsrafferty »

matijsvzuijlen wrote: post #396
chipsrafferty wrote: post #358

Earlier quoted context omitted.

I don't think it's as cut and dry as that. In my team we require 100% test coverage. Every file requires an accompanying test file, and every test file is set up with a bunch of mocks. Sure, we could take the Foo, Bar, and Baz tables that share 80-90% of common logic and have them inherit from a common, shared, abstract component. We've discussed it in the past. Maybe it's the better solution, maybe not. But it would…

I can understand requiring 100% test coverage, but it seems to me that requiring a test file for every file is preventing your team from doing useful refactoring. What made your team decide on that rule? Could your team decide to drop it since it hinders improving the design of your code?

Honestly, I've never questioned it. The upside seems that yes, it could make refactoring easier. Downside, though, is not knowing where certain tests live. The command+shift+T shortcut to open the test file corresponding to a production code file is very useful to me, too.

Thanks, I'll have a think about it

Re: Cognitive load is what matters

#542

Post by chipsrafferty »

MrDarcy wrote: post #369
chipsrafferty wrote: post #356

Earlier quoted context omitted.

I think the most common way to approach that problem would be to have a "default config", and overrides. Could you go into more detail about why you didn't do this instead? Downsides with your approach is: 1. Now whenever you want to change something both in Europe and (assuming) USA you have to do it in 2 places. If the change is the same for both, in my system, you could just update the default/shared config. If th…

I don’t do this because with a complete copy I get progressive rollouts across regions without the complexity of if statements and feature flags. That is to say, making the change twice is a feature not a bug when the changes are staggered in time. From an operational perspective it’s much more important to ensure the code is clear and readable during an incident. Overrides are like inheritance. They are themselves c…

> with a complete copy

Ok, so make a build script that creates a complete copy for each separate config from the default config and the overrides. Then use the complete copies.

> I easily see the one line diff among hundreds of thousands using… diff.

Yes, and in 5 years when it's not just 1 line?

Your approach does NOT scale. You just haven't scaled yet and haven't realized this.

Re: Cognitive load is what matters

#544

Post by tartoran »

lilerjee wrote: post #165

Cognitive Load is not what matters, Solving problems is what matters. "Cognitive Load" is a buzzword which is abstract. Cognitive Load is just one factor of projects, and not the main one. Focus on solving problems, not Cognitive Load, or other abstract concepts. Use the simple, direct, and effective method to solve problems. Cognitive Load is relative, it is a high Cognitive Load for one person, but low cognitive lo…

> Cognitive Load is not what matters, Solving problems is what matters.

> Use the simple, direct, and effective method to solve problems.

You seem to contradict yourself, while you mention cognitive load is not what matters you prescribe a way to lower cognitive load. I've seen projects explode in complexity and then die and that was mainly to unmanageable cognitive load required to make changes.

Re: Cognitive load is what matters

#545

Post by lilerjee »

tartoran wrote: post #544
lilerjee wrote: post #165

Cognitive Load is not what matters, Solving problems is what matters. "Cognitive Load" is a buzzword which is abstract. Cognitive Load is just one factor of projects, and not the main one. Focus on solving problems, not Cognitive Load, or other abstract concepts. Use the simple, direct, and effective method to solve problems. Cognitive Load is relative, it is a high Cognitive Load for one person, but low cognitive lo…

> Cognitive Load is not what matters, Solving problems is what matters. > Use the simple, direct, and effective method to solve problems. You seem to contradict yourself, while you mention cognitive load is not what matters you prescribe a way to lower cognitive load. I've seen projects explode in complexity and then die and that was mainly to unmanageable cognitive load required to make changes.

Solving problems is the purpose and focus.

How to solve problems?

The simple, direct, and effective method is good one method sometimes, not all time. For example, use very complicated method to obfuscate code in order to increase the difficulty of cracking, and there are many environments to use complicated code or methods.

So one is the purpose, one is the method.

Do not think "Lower Cognitive Load" is the purpose.

"Lower Cognitive load" is just the by-product sometimes, not the purpose.

Re: Cognitive load is what matters

#546

Post by positr0n »

hinkley wrote: post #282
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…

Some people use a gardening metaphor for code, and I think that since code is from and for humans, that’s not a terrible analogy. It’s organic by origin if not by nature. When you’re dealing with perennial plants, there’s only so much control you actually have, and there’s a list of things you know you have to do with them but you cannot do them all at once. There is what you need to do now, what you need to do next…

> More practical people see it as pretentious bullshit.

Or they just like spending time outside messing with plants? You could even call it a type of hacking if what you're trying to accomplish requires "a high degree of skill".

Re: Cognitive load is what matters

#547

Post by diegobit »

I think these books and resources should not be viewed as hard rules, but as sets of examples explaining guiding principles, and the internet is full of discussions that turn into religious wars over it.

It is always worth it for a programmer to dwell over what complexity is according to Osterhaur; it is worth it to reason over what Uncle Bob thinks is "clean" code, etc. I'm not benefiting from either by applying what they say dogmatically, but I improve my taste in what is good software to me, by discovering and trying many approaches. Without reading them I might never even have thought at a particular solution, or a particular frame of mind.

Re: Cognitive load is what matters

#550

Post by 1123581321 »

darkstarsys wrote: post #69
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…

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.

Amanda is just the light side of Mort, Elvis or Einstein, since keeping things simple and reviewable can mean staying business-oriented, using the right technology or using an existing tool with deep knowledge.

We would all like our coworkers to never make bad decisions. :)

Post reply on HN