Cognitive load is what matters

The ability to create code that imposes low cognitive load on others not only is a rare and difficult skill to cultivate- it takes active effort and persistence to do even for someone who already has the ability and motivation. I think fundamentally the developer is computing a mental compression of the core ideas - distilling them to their essence - and then making sure that the code exposes only the minimum essential complexity of those ideas. not easy and rare to see in practice

And if you do it really well, people think it must have been such an easy problem to solve all along. Since everything always appears so obvious in insight.

While the castle of cards of unfathomable complexity is praised for visibly hard work and celebrated with promotions.

Plus rarely survives requirements/context changing because most abstractions are leaky.

My favourite frameworks are written by people smart enough to know they're not smart enough to build the eternal perfect abstraction layers and include 'escape hatches' (like getting direct references to html elements in a web UI framework etc) in their approach so you're not screwed when it turns out they didn't have perfect future-sight.

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

This is also true of interface/UX/interaction design. Most developers are really skilled at maintaining a higher cognitive load than most, and the interfaces that work best for less technical people often frustrate developers, who want everything in front of them, visible, at all times because they intuitively know what’s important. Interfaces created by developers might click with other devs, but often bewilder less technical people. It’s really hard to design a tool that less technical people can use intuitively to solve complex problems without wanting to throw their electronics out the window.

It is! But it’s also a bonus rather than a requirement for a lot of firms. For proof, look at any major codebase.

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

But only if you make it look like an electrical thing

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.

I think one issue is that some people just find very different things intuitive. Low cognitive load for one person might be high cognitive load for another.

Because of some quirk of the way my brain works, giant functions with thousands of lines of code doesn't really present a high cognitive load for me, while lots of smaller functions do. My "working memory" is very low (so I have trouble seeing the "big picture" while hopping from function to function), while "looking through a ton of text" comes relatively easily to me.

I have coworkers who tend to use functional programming, and even though it's been years now and I technically understand it, it always presents a ton of friction for me, where I have to stop and spend a while figuring out exactly what the code is saying (and "mentally translating" it into a form that makes more sense to me). I don't think this is necessarily because their code inherently presents a higher cognitive load - I think it's easier for them to mentally process it, while my brain has an easier time with looking at a lot of lines of code, provided the logic within is very simple.

And, furthermore - being a "noisy Nancy" is often a bad move for your career, socially. As I age, I realize it's more important to get along in most corporate/professional settings than it is to be the person fixing things.

All work represents a social entity (person/persons) and when you're the one calling out issues, pushing for proactive measures, and pushing against bad practices/complexity you're typically taking issue with _someone's_ work along the way. This is often seen as a "squeaky wheel" or "noisy Nancy" - or hell, outright antisocial. Most of the time it is not in your best interest to be this person.

The people who keep their nose down + mouth shut, those who prioritize marketing their work, and the sycophants are the ones who have longevity and upward trajectory - this is corporate America work culture.

And ironically, writing code that is maintainable on the long run and imparts a low cognitive load on successive developers is itself a cognition consuming effort.

In tradeoff engineering, maintainability over the long term is one of the many variables to optimize, and finite resources need to be alloted to it.

When I read this article I get the feeling that it's more likely that he is obsessing over maintainability over the long term while his app has a user count of zero. This malady usually comes from the perspective of being a user, one finds that the experience of writing some code is a "bad experience" so they strive to improve it or learn how to build a good "coder experience", the right answer is to understand that one is stepping into the shoes of the plumber, and it will be shitty, just gotta roll up your sleeves.

Don't get me wrong, there's a lot of wisdom here, but to the extent that there is, it's super derivative and well established, it's just the kind of stuff that a developer learns on their first years of software by surfing the web and learning about DRY, KISS and other folklore of software. To some extent this stuff is useful, but there's diminishing returns and at some point you have to throw shit and focus on the product instead of obsessing over the code.

This was maybe a problem years ago, but I don't think its a pro lem these days. I see many more cases of the opposite problem, interfaces that are meant of technical users but are designed using modern mobile centric paradigms, over emphasizing negative space and progressive disclosure.

this is also a problem for tools designed for non-technical users for complex tasks that are performed frequently. your power users needs a powerful interface even if they are less technical.

Those interfaces are not likely designed by interface designers — they’re either assembled by developers using framework libraries trying mimic things that ‘look designed,’ or “designed” by visual designers that have no more business designing interfaces than Wordpress plugin developers have designing your network architecture. Your first clue is your citing the ‘mobile first’ design— The first step in any serious interface design is researching who your users are, what they need, in what environment, and with what tools. Something being mobile-first is an implementation detail that has nothing to do with the core design. You don’t notice well-designed interfaces because if it’s properly designed, you concentrate on solving your problem and not the tool that’s solving it. If you’ve got primarily technical users and you’re not giving them technical tools, or you have a lot of power users and aren’t giving them power user tools, you probably didn’t do the thing that every subsequent decision in the design process should be based on: research the who, what, where, why, and when of the interface.

The problems you cite aren’t caused by bad design, but a lack of design, altogether.