[picometer]

I’ve had a variety of responses to this list over my programming life (~10 years hobby, ~10 years professional).

When I first encountered them as a hobbyist, they were surprising, as perhaps intended, due to the framing of classic vices as virtues. On some reflection though, it made sense, and shaped my understanding of programming as somehow _inherently different_ than other types of creation.

When I got started with a professional career, they functioned to soften the edge of anxiety. It meant that the community of programmers who came before me - which presumably included Larry Wall - would understand that these patterns in coder behavior were ultimately beneficial and that I would maybe fit in with a corporate programming environment. (Now I know that this isn’t always true; sometimes coworkers, both programmers and non-programmers, don’t always realize these unintuitive points, and in some special cases, those programmer instincts aren’t actually valuable.)

At some point, I disagreed with the framing. As others have pointed out, the patterns can be reframed as classic or functional virtues such as curiosity. Then I backpedaled and realized that the framing is important because these are unintuitive patterns and it makes us re-think habitual incentives that reward, e.g., work that is more productive but not more effective.

How did it hit me now? I realize that it’s also related to power dynamics. Programmers are assets to their employers but they’re also potential disrupters. The traditional “virtuous” framing of potentially-less-effective behavior, like patience, is related to the organizing and taming of a workforce.

It’s also related to the types of problems we encounter. When we work with computers, Larry’s list does usually lead to more effective outcomes. But when working with other humans, who have their own agency and idiosyncrasies, the traditional virtues are better-adapted behavior. This is also more true for the complex technical systems we deal with nowadays. So, as our careers transition from programming to system engineering and/or management, the traditional virtues become more relevant.

Anyhow, this is an evergreen and thought-provoking nugget of wisdom. Thanks to Larry Wall and those who have preserved it.

[h0l0cube]

The main annoyance I have with Larry’s take is that efficiency is confused with laziness, which are entirely different things. Laziness, at its extreme, is to delay doing something until absolutely necessary, or even avoid entirely, efficiency is to optimize for the least possible effort, which is sometimes the same as being lazy