But trust also degrades naturally over time. Italian researchers Cristiano Castelfranchi and Rino Falcone have a model of trust in which it’s observability not success that is the key factor. Under their theory an entity that is silently successful can end up seen as less trustworthy than an entity that visibly fails. If we recover from failure quickly and efficiently, trust increases. Whereas when we succeed and no one notices we become more and more unknown and uncertain. This explains what is known as the service recovery paradox, when consumers trust a service provider more after a failure than they did before the failure.

https://medium.com/@bellmar/all-the-best-engineering-advice-i-stole-from-non-technical-people-eb7f90ca2f5f

Effective teams need trust. That’s not to say that frameworks for decision making or metrics tracking are not useful, they are critical but replacing trust with process is called bureaucracy. The trust must exist first in order for KPIs, OKRs, SLOs (or whatever acronym is selling books now) to work.

https://medium.com/@bellmar/all-the-best-engineering-advice-i-stole-from-non-technical-people-eb7f90ca2f5f

Doing things for people is rarely as helpful as it seems like it should be. If they don’t understand what you built, you’ve made things worse. If they don’t know how to maintain it, you’ve made things worse. If you didn’t know enough about their requirements to get implementation correct, you’ve made things worse. If they don’t care about using or maintaining the thing you’ve built because they didn’t build it and have no sense of ownership or obligation to it, you’ve made things worse.

https://medium.com/@bellmar/all-the-best-engineering-advice-i-stole-from-non-technical-people-eb7f90ca2f5f

Paradoxes of Software Architecture #1: Flexibility Breeds Complexity

http://www.informit.com/articles/article.aspx?p=1963779

Performance changes how users use software

It’s probably fairly intuitive that users prefer faster software, and will have a better experience performing a given task if the tools are faster rather than slower.

What is perhaps less apparent is that having faster tools changes how users use a tool or perform a task. Users almost always have multiple strategies available to pursue a goal — including deciding to work on something else entirely — and they will choose to use faster tools more and more frequently. Fast tools don’t just allow users to accomplish tasks faster; they allow users to accomplish entirely new types of tasks, in entirely new ways.

https://blog.nelhage.com/post/reflections-on-performance/

Developer Efficiency

OOP

I used to tolerate and expect complexity. Working on Go the past 10 years has changed my perspective, though. I now value simplicity above almost all else and tolerate complexity only when it's well isolated, well documented, well tested, and necessary to make things simpler overall at other layers for most people. https://bradfitz.com/2020/01/30/joining-tailscale

Simple vs easy / complex vs hard: https://www.youtube.com/watch?v=LKtk3HCgTa8

Five worlds and discussion

https://sans-io.readthedocs.io/how-to-sans-io.html

State intertwines "value" and "time", so that to reason about the value of a piece of state you have to reason about time (like the interleaving of operations that could mutate the state)

Supposedly from SiCP Ch 3

Other notes

https://siderea.dreamwidth.org/1209794.html