Four short links: 9 July 2020
Fallback, Observability, Developer Productivity, and Explorable Explanations
- Avoiding Fallback in Distributed Systems — In this article, the focus will be on how fallback strategies can cause more problems than they fix. We’ll include examples of where fallback strategies have caused problems at Amazon. Finally, we’ll discuss alternatives to fallback that we use at Amazon.
- So You Want to Build an Observability Tool — It may not be as catchy as “three pillars”, but in order to claim your tool delivers observability, it should support/deliver the following: Arbitrarily-wide structured raw events; Context persisted through the execution path; Without indexes or schemas; High-cardinality, high-dimensionality; Ordered dimensions for traceability; Client-side dynamic sampling; An exploratory visual interface that lets you slice and dice and combine dimensions; In close to real-time.
- What Predicts Software Developers Productivity? — Our results suggest that the factors that most strongly correlate with self-rated productivity were non-technical factors, such as job enthusiasm, peer support for new ideas, and receiving useful feedback about job performance. Compared to other knowledge workers, our results also suggest that software developers’ self-rated productivity is more strongly related to task variety and ability to work remotely.
- Loopy — I love visual simulations, especially interactive ones, as a way of generating deep understanding of a complex situation. This lets you build a model of interactions and levers, and then you play with it as it simulates flow through the system. It’s not complex, and you can probably think of ways to improve it (you can, it’s open source). But what do you understand that you could simulate for your colleagues to better understand?
