Issue #714, 31st July 2026

This Week's Favorite


A Carefully Organized Library of Public Engineering Incident Reports, Postmortems, and Shutdown Writeups
5 minutes read.

A great archive of public incident writeups and startup shutdown postmortems. Worth keeping open the next time you're writing your own postmortem and want a structure to copy. Share it with your teammates and try running it with a coding agent to see which relevant lessons learned apply to your codebase so you can prevent the incident before it happens.

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


Culture


POV: Software Engineers Just 3 Hours Before the Deadline
1 minutes read.

My humble effort to help you start the weekend with a smile.

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


Ideas Over Implementation
3 minutes read.

Every word here is so important and valuable. Read it slowly: "If you anchor yourself to the objective instead of the implementation, you give yourself room to course-correct when reality pushes back. Early decisions are made with the least information. Treating them as sacred just makes learning more expensive. [...] That flexibility isn’t indecision. It’s respect for the fact that understanding improves with motion."

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


Rude Ducking
2 minutes read.

Sarah Guo on procrastination dressed up as diligence: "A founder who delays a launch to keep polishing or iterating scope or positioning is putting off making contact with reality." What's the launch, decision, or hard conversation you're still polishing instead of shipping?

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


Reinventing the Wheel, Now at A Bargain Price!
7 minutes read.

Ian Miell flips twenty years of "don't reinvent the wheel" on its head: LLMs made narrow, purpose-built code cheap right as supply-chain governance made every dependency a recurring bureaucratic obligation, from CVE triage to SBOM entries. Where does your team's dependency count actually earn its keep, versus just sitting there waiting for the next left-pad moment?

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


Peopleware


How I Find Problems to Solve as a Staff Engineer
6 minutes read.

"Absorb problems, not requests" is the takeaway you should frame in your brain and keep iterating on when talking with your peers. This is how you create buy-in from potential future users of the solution you build: "When a problem seems worth exploring, though, I become more active; I need to see how it affects the team’s day-to-day work. I’ll sit with them as they walk me through their workflows and the bugs they’re investigating. When I can, I’ll try working through some of those bugs myself. Seeing the problem firsthand makes it easier to separate what the team actually needs from the solution they asked for."

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


Jack Dorsey, Co-Founder of Block, on His Biggest Leadership Mistake: Delegating Too Much.
3 minutes read.

Jack Dorsey's biggest regret at Block was delegating too much: Splitting Square and Cash App under separate CEOs looked like a scaling move, but it quietly turned the company into a holding company instead of one integrated financial platform. Delegation without a unifying thesis is a disaster waiting to happen. But my take is that the second the CEO is not driving the company with their own energy, but rather relies only on structure, entropy wins, and the company gets misaligned.

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


Teaching Systems to Keep Promises
11 minutes read.

It's incredibly hard to run regression tests with enough coverage to feel confident when making a change in a brownfield project with massive dependencies (upstream and downstream). Omer van Kloeten shares a path forward to help with such an approach, based on your code ("The code remembers, we don't") as the source of truth.

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


Inspiring Tweets


@Jason: I have now learned that <10% of humans perform better working from home. 10-20% are as good working from home 75-80%+ perform better at the office 90% of founders/managers are better at leading in-office — 10% are capable of managing primarily remote teams What’s your first-hand experience?

@peer_rich: engineering went from no tests, to test driven development, to only reading tests

- 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!