Wiki Contributions


Thanks for sharing your perspective. I remember you describing your experience in a little more depth some time ago and it makes me doubt my experience. Perhaps I've been in less healthy orgs. But more likely there are knobs/patterns I can't see, so org change work like this feels out of reach for me. I've got some thinking to do.

I've been thinking about AllAmericanBreakfast's recent shortform posts about mentition. It's because I've been teaching myself three new things and I noticed that one practice I engage in regularly is playing with problems in my head. But this practice seems to largely depend on how good I am at something.

Anecdotal examples:

  • Teaching myself TLA+. It's a programming language used to specify models, which helps verify whether an algorithm behaves like it should, especially concurrent algorithms.
    • I have a few examples that I've looked at (from the course). Throughout the day, I'll turn these around in my mind, looking at different facets, moving things around and occasionally hit on an insight.
  • Going through Bayesian Statistics the Fun Way for a much needed refresher on bayesian stats.
    • Here too I have a few simple examples, problems taken straight from the book, that I turn over in my head. It's harder, though, because different "objects", like numerators and denominators, are hard for my mind to hold onto for long. I need more focus.
  • Writing. Specifically, creative nonfiction.
    • Here, I have a few essays that I really liked that I'm playing with. But this one is the hardest of all to wrestle with in my mind. Ideas, sentences, paragraphs feel so liquid and unholdable. I can only do this type of work with pen and paper or a text editor.

In the first case, in which I have some years of experience, thinking and focusing feels easy. Even in a weird language I've never seen before, I can see "things" and "relationships" and "sequences" and play around with them.

In the last case, there are almost no things, no relationships. It's all one mixed up soup. Only recently did I learn, thanks to a class, about things like ledes, nut graphs, points/themes, angles, calls to action, etc. and this has been an immense help in slowly learning how to "turn around" these things in my mind.

So, if this generalizes in any way, it seems that ramping up to a state where you can do mentition requires first learning to see the structure of whatever it is you're learning. Sort of like priming the pump. Afterwards, there's a lot less "ugh" and a lot more play.

I've seen this happen too, along with same end result.

It appears that a common failure mode here is that the middle management layer fails to translate the values into system updates. No one updates performance reviews, no one updates quarterly/half goals, etc. So things just continue as they were before.

Ultimately, it's the responsibility of leadership to fix this. Whether it's by direct intervention or a huddle with middle management, they must do something.

(My experience as an individual contributor that attempted to change how performance reviews are done to better align with a value like "engineering excellence" tells me it's impossible to affect this kind of change as an IC. Unless you're friends with the CEO, which I wasn't).

Thanks for posting this. I'll add it to my collection of "thinking tools."

These techniques feel like they have the same spirit as some of de Bono's work, for example, his idea of PO:

PO implies, 'That may be the best way of looking at things or putting the information together. That may even turn out to be the only way. But let us look around for other ways.

The two main functions of PO are first to protect an arrangement of information from judgement and to indicate that it is being used provocatively and second to challenge a particular arrangement of information such as an idea, a concept or a way of putting things.

Some of them also remind me of Gerald Weinberg's books, but unfortunately I can't find my notes on them.

In my experience with doing something similar, this practice also helps memorize adjacent concepts.

For example, I was recently explaining to myself Hubbard's technique that uses Student's t-stat to figure out the 90% CI of a range of possible values of a population using a small sample.

Having little memory of statistics from school, I had to refresh my understanding of variance and the standard deviation, which are required to use the t-stat table. So now, whenever I need to "access" variance or stdev, I mentally "reach" for the t-stat table and pick up variance and stdev.

Thirding this. Would love more detail or threads to pull on. Going into the constructivism rabbit hole now.

That was my idealism/naivete: that the league of liberal democracies is so mature and strong that they could flip a switch and the war would cease. Maybe they would just tell Putin to stop and he would have to. Because for me, democracy was always a guarantee of peace. But the war made me realize my map was way off from the territory, and Popper's book, in turn, helped to replace my fantasy with something closer to the territory.

This echos an excellent post by Dan Luu that touches on problems you face when you build larger, less legible systems that force you to deal with normalization of deviance:

The action items he recommends are:

Pay attention to weak signals

Resist the urge to be unreasonably optimistic

Teach employees how to conduct emotionally uncomfortable conversations

System operators need to feel safe in speaking up

Realize that oversight and monitoring are never-ending

Most of these go against what is considered normal or comfortable though:

  1. It's difficult to pay attention to weak signals when people build awful attention traps (eg. tiktok, youtube, etc.)
  2. People are commonly [overconfident]( 
  3. Uncomfortable conversations are uncomfortable. In certain cultures, it's better to straight out lie rather than deliver bad news.
  4. Few organizations have set up channels for upwards communication where front line employees can flag problems. It's better to not rock the boat.
  5. Constant oversight and monitoring are mentally and physically draining.  These are also the easiest activities to cut from a budget because they're not visible until an accident happens.

What the boy should have done is establish an organization (Wolf-Spotters) whose responsibility is monitoring for signs of wolves. This organization could be staffed by professional or volunteer observers. They need to do periodic trainings and live-action drills (perhaps using a wolf suit). To the fund this, the boy should have first created a PR campaign to make people aware of the cost of unspotted wolves (death), then use that to get support of some local politicians.

(It's basically a fire department). 

If the boy was open to using the dark arts, he could have executed a false flag wolf attack. That would incentivize local politicians to support his cause.

Enjoy Portland! Btw, if you want to hang out with some cool people, there's a rationalist space in Seattle called The Territory full of cool people. 

Some people seem to do this automatically. They notice which things make code harder to work with and avoid them. Occasionally, they notice things that make working with code easier and make sure to include those bits in. I guess that's how you get beautiful code like redis or Django.

But I've never seen any formal approach to this. I've gone down the software craftsmanship rabbit hole for a few years and learned a lot thanks to it, but none of it was based on any research--just people like Beck, Uncle Bob, Fowler, etc. distilling their experience into blog posts or books. The downside of that is that it would ignite furious debate that would go nowhere because there was no data to back it up, just anecdotes. These debates, I think, turned a lot of people off, even though there were gems of wisdom there.

Load More