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

251–260 of 552 posts

Re: Cognitive load is what matters

#251

Post by Swizec »

citizenpaul wrote: post #197
Swizec wrote: post #8

Earlier quoted context omitted.

> So, is pile-of-if-statements the best we can do for business software? You’ll enjoy the Big Ball of Mud paper[1]. Real world systems are prone to decay. You first of all start with a big ball of mud because you’re building a system before you know what you want. Then as parts of the system grow up, you improve the design. Then things change again and the beautiful abstraction breaks down. Production software is alw…

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

Much of engineering is about building systems to keep the mess manageable, the errors contained, etc. And you have to do that while keeping the system running.

Re: Cognitive load is what matters

#252

Post by lukeschlather »

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.

I don't really like the axes Mort/Elvis/Einstein are on, they all seem like obviously pathological examples.

I think if I were to make three strawmen like this I would instead talk about them as maximizing utility, maintainability, and effectiveness. Utility because the "most business value" option doesn't always make the software more useful to people. (And I will tend to prioritize making the software better over making it better for the business.) Maintainability because the thing that solves the use case today might cause serious issues that makes the code not fit for purpose some time in the future. Effectiveness because the basket of if statements might be perfect in terms of solving the business problem as stated, but it might be dramatically slower or subtly incorrect relative to some other algorithm.

Mort is described as someone who prioritizes present business value with no regard to maintainability or usefulness.

Elvis is described as someone who prioritizes shiny things, he's totally a pejorative.

Einstein is described as someone who just wants fancy algorithms with no regard for maintainability or fitness to the task at hand. Unlike Elvis I think this one has some value, but I think it's a bit more interesting to talk about someone who is looking at the business value and putting in the extra effort to make the perfectly correct/performant/maintainable solution for the use case, rather than going with the easiest thing that works. It's still possible to overdo, but I think it makes the archetype more useful to steelman the perspective. Amanda sounds a bit more like this, but I think she might work better without the other three but with some better archetypes.

Re: Cognitive load is what matters

#253

Post by zakirullin »

insanebrain wrote: post #243

I love love love monorepo + fat encapsulated modules + a couple of deployables. Why does the software industry create fake complexity/creativity in the craft? Fashion/hype architectures for dopamine and fulfilment. You're just wasting energy finding new ways to create machine code for hardware. Why not get creative in the hardware and actually make something new? Another thing that really grinds my gears, is how many…

Agreed on every point! From what I observed, some engineers try to express themselves through exciting architectures. They are proud of it, they get their dopamine. Their craft can't be simple, if it is simple then they are dull too. At some point in time some of them stop associating their code with themselves, and take somewhat business approach. Most of them do not pass this point, unfortunately.

Re: Cognitive load is what matters

#254

Post by zakirullin »

insanebrain wrote: post #243

I love love love monorepo + fat encapsulated modules + a couple of deployables. Why does the software industry create fake complexity/creativity in the craft? Fashion/hype architectures for dopamine and fulfilment. You're just wasting energy finding new ways to create machine code for hardware. Why not get creative in the hardware and actually make something new? Another thing that really grinds my gears, is how many…

I also find JS and all the infrastructure very mentally taxing. Building a legacy project via some esoteric and already out-of-fashion build system is so painful. Thousands of dependencies, hundreds of issues and warnings...

Re: Cognitive load is what matters

#255

Post by computerdork »

I completely agree with every in this article, but seems like it's just at different way of looking at the well-known software-engineering concept of "complexity." Yeah, the main difference is cognitive load is considering the complication of the system from how it effects the developer, while complexity focuses on the amount of complications in the system itself.

Yeah, if you go through this article and replace most of the places where it mentions "cognitive load" with "complexity," it still makes sense.

Yeah, this isn't a criticism of the article - In fact, there are important difference, like having more of a focus on what the dev is experiencing handling the complications of the system - But for those really interested in its concept, may want to learn about complexity too, as there is a lot of great info on this.

Re: Cognitive load is what matters

#257

Post by neonrider »

Love it. Make code accessibility a first-class citizen. Turn the rule books and their principles into guidelines. A smart coder knows to follow rules. A master knows code is meant to be read and develops contextual awareness for when and why to break a rule, or augment it, as the case may be. So, reintroduce judgment and critical thinking in your coding practice. Develop an intuitive feel for the cognitive costs and trade-offs of your decisions. Whether you choose to duplicate or abstract, think of the next person (who sometimes is you in six months).

For those asking why author doesn't come up with their own new rules that can then be followed, this would just be trading a problem for the same problem. Absentmindedly following rules. Writing accessible code, past a few basic guidelines, becomes tacit knowledge. If you write and read code, you'll learn to love some and hate some. You'll also develop a feel for heavy handedness. Author said it best:

> It's not imagined, it's there and we can feel it.

We can feel it. Yes, having to make decisions while coding is an uncomfortable freedom. It requires you to be present. But you can get used to it if you try.

Re: Cognitive load is what matters

#258

Post by packetlost »

pessimizer wrote: post #132
makeitdouble wrote: post #123

Earlier quoted context omitted.

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

Your definition of elegant is definitely different from mine lol

Re: Cognitive load is what matters

#259

Post by zakirullin »

andix wrote: post #226

I had the exact same experience with layered architectures like described in this article. Avoid them as much as possible, naive and simple code is often better. It might look messy on the surface, and the layered code might look much cleaner. Until you drown in indirections, that are impossible to keep track of.

It seems like some engineers have emotional attachment to all these layered architectures. Explaining or giving them examples of failed projects (based on this architecture) doesn't help.

Re: Cognitive load is what matters

#260

Post by whstl »

kibwen wrote: post #47
eastbound wrote: post #34

Earlier quoted context omitted.

> consider how short software engineer tenures are! Employees aren’t fired. They leave for a 10% increase. Employees are the ones who seek always more in a short-termist way.

At the same time, the reason that employees leave on such a regular cadence is precisely because the companies they work for refuse to give them the salary increase that they could get by going elsewhere. Companies could solve this by giving commensurate raises.

They would rather give a 10% increase to the guy replacing you.
Post reply on HN