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

151–160 of 552 posts

Re: Cognitive load is what matters

#151

Post by pessimizer »

xmprt wrote: post #142

This is one of the reasons I fear AI will harm the software engineering industry. AI doesn't have any of these limitation so it can write extremely complex and unreadable code that works... until it doesn't. And then no one can fix it. It's also why I urge junior engineers to not rely on AI so much because even though it makes writing code so much faster, it prevents them from learning the quirks of the codebase and…

Thus far, and granted I don't have as much experience as others, I just demand that AI simplify the code until I understand everything that it is doing. If I see it doing something in a convoluted way, I demand that it does it in the obvious way. If it's adding too many dependencies, I tell it to remove the goofy ones and write it the long way with the less capable stdlib function or helped by something that I already have a dependency on.

It's writing something for me, not for itself.

Re: Cognitive load is what matters

#152

Post by pessimizer »

n4r9 wrote: post #149
pessimizer wrote: post #132

Earlier quoted context omitted.

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.)

True, but we shouldn't understate how beneficial elegant solutions can be in the appropriate setting. Sometimes you read code that gives you a new and memorable way to think about a certain kind of problem.

I agree we like it. I don't want to have to review it. I'd rather review code where the bugs stick out like blinking yellow lights, even if it runs 10% slower (or 1000% slower, if I'm only running it once.)

Re: Cognitive load is what matters

#153

Post by dsego »

mupuff1234 wrote: post #148
xmprt wrote: post #142

This is one of the reasons I fear AI will harm the software engineering industry. AI doesn't have any of these limitation so it can write extremely complex and unreadable code that works... until it doesn't. And then no one can fix it. It's also why I urge junior engineers to not rely on AI so much because even though it makes writing code so much faster, it prevents them from learning the quirks of the codebase and…

Or maybe it will actually increase the quality of software engineering because it will free up the cognitive load from thinking of the low level design to higher level architecture.

That's my fear, it will become a sort of a compiler. Prompts will be the code and code will be assembly, and nobody will even try to understand the details of the generated code unless there is something to debug. This will cause the codebases to be less refined with less abstraction and more duplication and bloat, but we will accept it as progress.

Re: Cognitive load is what matters

#154

Post by tenacious_tuna »

supportengineer wrote: post #63

Large software projects built by humans will always be doomed to fail, because humans like to build the new, and nobody likes to maintain the old.

I've very much enjoyed maintaining or optimizing or hardening existing systems--I can just never convince my leadership to let me do that.

My current org has a terrible case of not-invented-here syndrome, and it's so easy to pitch new projects that solve something that there's already an existing tool for, or building a new feature. We would love to spend time just working within our existing systems and fixing crap abstractions we made under the deadline-gun, but we're not "allowed" to.

> [...] humans like to build the new, and nobody likes to maintain the old

I think this is certainly true at organizational scale, but most of the people I've met are change-resistant overall.

Re: Cognitive load is what matters

#155

Post by rawgabbit »

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.

They were also missing Steve Jobs. Having had the displeasure to work with Microsoft tools and code for most of my career. Microsoft never in my experience just plain works. I had to fight Microsoft every step of the way to get things to "work". And when it does it invariably breaks in the next major software release.

Re: Cognitive load is what matters

#156

Post by mupuff1234 »

dsego wrote: post #153
mupuff1234 wrote: post #148

Earlier quoted context omitted.

Or maybe it will actually increase the quality of software engineering because it will free up the cognitive load from thinking of the low level design to higher level architecture.

That's my fear, it will become a sort of a compiler. Prompts will be the code and code will be assembly, and nobody will even try to understand the details of the generated code unless there is something to debug. This will cause the codebases to be less refined with less abstraction and more duplication and bloat, but we will accept it as progress.

Funny, I'd say that codebases nowadays usually have too many abstractions.

Re: Cognitive load is what matters

#158

Post by RaftPeople »

jadbox wrote: post #107
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.

Mort, Elvis, Einstein, Amanda does seem to fit well with my experience. While people are a mix, generally I think its fair that there is a primary focus/mode that fits on career goals. - Mort wants to climb the business ladder. - Elvis wants earned social status. - Einstein wants legacy with unique contributions. - Amanda just wants group cohesion and minimizing future unpredictability.

> - Mort wants to climb the business ladder.

I think the personas have some validity but I don't agree with the primary focus/mode.

For example, I tend to be a mort because what gets me up in the morning is solving problems for the enterprise and seeing that system in action and providing benefit. Bigger and more complex problems are more fun to solve than simpler ones.

Re: Cognitive load is what matters

#159

Post by hackerthemonkey »

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…

And eventually it took 3 years.

Re: Cognitive load is what matters

#160

Post by fcantournet »

Buttons840 wrote: post #61
dsego wrote: post #53

Earlier quoted context omitted.

> x = 4 // assign 4 to x Ah, the chat gpt style of comments. > Instead do something like: The only negative is that there is a chance the comment becomes stale and not in sync with the code. Other coders should be careful to update the comment if they touch the code.

If the what becomes stale, you can tell. If the why becomes stale (and it can become stale), you'll never know, unless the what is also included.

The why becoming stale is a feature, that's when you know there is a VALID reason you thought this looked weird and convoluted, instead of you completely missing the inherent complexity of the problem.
Post reply on HN