From the TL;DR in Tech archive, originally sent on Substack. Some links may have died since.

tl;dr in tech by Joe Karlsson - Issue #6

tl;dr: Derek shares his design review process, starting with the design doc (he shares his template) through to the in-person meeting, where he outlines specifics around planning, moderation and process. This review process helps with org-wide comms, understanding of technical infrastructure, knowledge of legacy work & current projects, better design, and saves time.

tl;dr: Jessica discusses “participatory sense-making.” In software, this is developing a shared mental model of the software we’re developing, what it’s going to be, how it works. In humanity, participatory sense-making is our shared reality of made-up concepts i.e. money, economy, justice, etc… “When we’re good at participatory sense-making, we can build conscientiously, instead of reducing everything to numbers.”

tl;dr: Operational Surprises (OOPS) is when something unexpected happened in operations and presents an opportunity to discover how the observed system behavior deviated from the mental model of how the system is supposed to behave. The template shared in this post is based on the template used at Netflix.

tl;dr: 8 best practices shared including:

1) Alerts are treated as code i.e. go through code reviews, generated from existing modules.

2) Use percentiles over averages to get a higher quality signal.

3) Use playbooks to document each alert so there is corresponding documentation that explains what is broken and how to investigate and fix it.

tl;dr: “Allow me a moment to go back through some of the most disastrous decisions or projects I ever agreed to (or even fought to do, sometimes):”

1) Don’t migrate an application from the data center to the cloud.

2) Don’t write your own secrets system.

3) Don’t run your own Kubernetes cluster and more.

tl;dr: Juliano discusses how each of the following five books helped him in his career:

1) The Passionate Programmer: Creating a Remarkable Career in Software Development.

2) The Pragmatic Programmer.

3) Unwritten Laws of Engineering.

4) Remote: Office Not Required.

5) Explain the Cloud Like I’m 10.

tl;dr: “Stories from 6 engineering leaders who succeeded in building and growing diverse teams,” with the following key takeaways:

1) Underrepresented leaders make a difference.

2) There are tactical wins you can start now e.g. bias training, partnering with organizations.

3) Use structure to drive diversity outcomes & create processes around those outcomes.

4) Tactics need a defined strategy and goals.

tl;dr: “We set out to make a simple and fast inner dev loop. The core shift that needed to be made was from the fully integrated environment of Onebox (many services), toward an isolated environment where only one service and its tests would run. This new isolated environment would be run on developer laptops. Users simply edit code and run tests with no additional steps in between.”

tl;dr: The following are elements of successful UB training detailed in this post:

1) You hold the power. Bias is often subtle and our brains are wired for change.

2) Create empathy by trying to understand where others are coming from.

3) Encourage interactions among people from different groups.

4) Encourage good practices and continued learning.

5) Set a broader strategy for more significant impact.

How we process large scale data in real time at Twitter while reducing latency and improving accuracy.