Michael Deng and Jonathan Chang:

Deploys require a careful balance of speed and reliability. At Slack, we value quick iteration, fast feedback loops, and responsiveness to customer feedback.

An interesting dive into how Slack handles deploys to a large fleet of users.

Cal Newport:

In the war to reclaim your attention, some battles have clearer fronts than others. It has become clear to me that these differences matter.

…

An attention charter is a document that lists the general reasons that you’ll allow for someone or something to lay claim to your time and attention. For each reason, it then describes under what conditions and for what quantities you’ll permit this commitment.

I use LucidChart for collaborative drawing at work but I’m going to give Excalidraw a crack over the next few weeks.

A solid collection of remote working advice. There is some overlap with the strategies I employ.

Elisabeth Hendrickson:

What I’ve learned is that if we want things to go fast, a sense of momentum is much more effective than a sense of urgency.

Will Larson:

Stories focus on the why, sharing the experience and context around the decision and results.

Stories also eliminate most of the least productive follow-up conversations after giving advice, where the advice-requester then argues against the advice. Stories relieve the advice-giver from the obligation to defend their advice. There’s nothing to agree or disagree with, just a recounting of past events.

Devon Price:

It’s really helpful to respond to a person’s ineffective behavior with curiosity rather than judgement.

…

If a person’s behavior doesn’t make sense to you, it is because you are missing a part of their context.

tef:

Every line of code written comes at a price: maintenance. To avoid paying for a lot of code, we build reusable software. The problem with code re-use is that it gets in the way of changing your mind later on.

…

Building reusable code is something that’s easier to do in hindsight with a couple of examples of use in the code base, than foresight of ones you might want later.

A look back at Carmack using academic research to improve rendering performance in the original Doom.

Jesse Frederik and Maurits Martijn:

Is online advertising working? We simply don’t know.

Kacper Gunia:

(we look at) how to handle writes to two independent backends without using two-phase commits. Instead we can rely on using at-least-once delivery guarantees and ask other systems to deduplicate our messages.

Inspired by CRDTs but simpler due to the server being a central authority.

Kent Beck comparing baskets of options to product roadmaps and goals:

I’ve come to hate the damage the “product roadmap” metaphor does to the brains of everyone involved in developing a product. When I use an actual map of actual roads, I assume that I know where I’m going and how I’m going to get there. This is never the case when developing a product.

…

When you encounter long lead times, you’re hearing option-on-a-basket thinking. “We need to know what features will be in the release in 8 months so Marketing has time to prepare.” What if product development doesn’t go according to plan? The value of the option on a basket falls to zero. What if the launch doesn’t come off? The value of the option on a basket falls to zero.

Gergely Orosz:

Estimates matter because most people and businesses are date-driven.

Estimation is difficult but developing it as a skill is helpful for delivering software.

Charity Majors:

it’s actually an unqualified good for engineers to be interacting with production on a daily basis, observing the code they wrote as it interacts with infrastructure and users in ways they could never have predicted.

…

A system’s resilience is not defined by its lack of errors; it’s defined by its ability to survive many, many, many errors. We build systems that are friendlier to humans and users alike not by decreasing our tolerance for errors, but by increasing it. Failure is not to be feared. Failure is to be embraced, practiced, and made your good friend.