←back to thread

1455 points nromiun | 4 comments | | HN request time: 0.603s | source
1. vdupras ◴[] No.45076824[source]
I don't know, I'm seduced by the elitist approach: code with a high cognitive load keeps mediocre developers away.

Case in point: Forth. It generally has a heavy cognitive load. However, Forth also enables a radical kind of simplicity. You need to be able to handle the load to access it.

The mind can train to a high cognitive load. It's a nice "muscle" to train.

Should we care about cognitive load? Absolutely. It's a finite budget. But I also think that there are legitimate reasons to accept a high cognitive load for a piece of code.

One might ask "what if you need to onboard mediocre developers into your project?". Hum, yeah, sure. In that case, this article is correct. But being forced to onboard mediocre developers highlights an organizational problem.

replies(2): >>45076888 #>>45083844 #
2. winwang ◴[] No.45076888[source]
This is an interesting take. I have a somewhat orthogonal viewpoint -- rather than "heavy cognitive load", I think that going somewhat off-mainstream is good for attracting, on average, better devs. For example, it's likely that the average Haskell dev spends more time honing their craft than the average Java dev. The article kind of touches on this (e.g. FP "vs" the more popular OOP) with familiarity vs simplicity though.
3. noportro ◴[] No.45083844[source]
> code with a high cognitive load keeps mediocre developers away.

That's true and it's a positive thing but the downstream consequences are often painful. We had a c/c++ project with complex memory management and heavy multithreadding, written that way because the superstar developer could handle the cognitive load and found the assignment intellectually challenging. That was great until they left for the next job.

We were left fighting a codebase with a big cognitive load, so we were desperately dependent on hiring more superstars just for routine maintenance. We eventually concluded that this wasn't a sustainable model and rewrote the system in plain old python. Much happier now.

replies(1): >>45088686 #
4. vdupras ◴[] No.45088686[source]
This is what I mean by "organizational problem". I understand that sometimes -- in fact most of the times -- you need to onboard mediocre programmers. But on the other hand, it's really great when you don't have to.