Issue #456, 20th August 2021

This Week's Favorite


Root Cause of Failure, Root Cause of Success
5 minutes read.

"When the boulder falls, it means that the collection of processes weren’t able to compensate for the disturbance. But there’s no single problem, no root cause, that you can point to, because it’s the collection of these processes working together that normally keep the boulder up." -- Important read by Lorin Hochstein you should share internally to build some understanding and appreciation for the humans involved in owning a complex system.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


Culture


When You’re Just a VC but Celebrate the IPO Like You Ran the Company the Whole Time
1 minutes read.

My humble effort to help you start the weekend with a smile on your face, even in this difficult time.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


Shipping Fast and Safe: Building a Culture of Low-Risk Learning
7 minutes read.

Kesha Mykhailov shares useful tips when testing the impact of your work (aka customer value) in production. "Ship the read path first" and "Ship instrumentation first" are not yet common as others (feature flags, canary deployment, etc.), so worth learning and experimenting with them if you haven't so far.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


Rethinking Best Practices
5 minutes read.

It's often the words we use that shape the culture we build. Very much like "postmortem" (we use BetterNext), you should consider your language and using the term "best practice" in your team. I love this framing: "We should regard best practices as provisional, not optimal, as a floor rather than a ceiling."

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


Why Is It So Hard to Decide to Buy? (Vs. Build)
8 minutes read.

"It’s easy to see the bill for your SaaS software every month, and hard to appreciate that the engineering cost to build an internal version is still probably higher because you haven’t factored in the opportunity cost of having engineers build that system instead of contributing to more core business opportunities." -- Camille Fournier covers well when to build versus buy, why it's hard for companies to build (and why it's often hard to buy) and how to set incentives correctly.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


Peopleware


Why You Feel Uncertain About Everything You Make
3 minutes read.

Tobias van Schneider with a short yet important reminder on the need to collect feedback while also forming a strong opinion: "Ask enough people for their opinion, and you’ll receive whatever answer you’re looking for – plus plenty more you didn’t want to hear. The feedback cancels itself out."

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


The Use of Spaced Repetition Memory Systems Has Changed My Life Over the Past Couple of Years. Here's a Few Things I've Found Helpful (Thread)
3 minutes read.

I love Michael Nielsen's work, and he made me go deeper into Spaced Repetition and try out Anki. Figuring out the right driver to practice it is key, or as Michael wrote it: "But what finally made Anki take was frustration that I'd never really learned the Unix command line." -- is there something you want to learn and remember? Try to find something that would be practical for your day-to-day work.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


DevTools Leverage
4 minutes read.

I cannot agree more with this recommendation: "Over the larger arc of your career, I'd recommend switching between roles every so often: build a product, build tools to make that experience better; go back and continue building the product; and repeat. You'll become a more rounded and effective engineer once you have experience across both sides. It's not a completely binary decision either; you could always split your time and play toolsmith for a part of the week."

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


Inspiring Tweets


@copyconstruct: Moving to kubernetes/any other platform to improve your reliability is the infra equivalent of rewriting your codebase in a different language for perf/stability etc. There might be some (debatable) gains, but there are *guaranteed* to be a slew of bugs and nasty surprises.

@ShaneAParrish: Finite games are won with intensity. Infinite games are won with consistency.

- Oren

P.S. Can you share this email? I'd love for more people to experiment and improve their company's culture.

Subscribe now & join our community!