Barack Obama:

But the point is, in just a few short weeks on the job, I had already realized that because every tough decision came down to a probability, then certainty was an impossibility — which could leave me encumbered by the sense that I could never get it quite right. So rather than let myself get paralyzed in the quest for a perfect solution, or succumb to the temptation to just go with my gut every time, I created a sound Decision Making process — one where I really listened to the experts, followed the facts, considered my goals and weighed all of that against my principles. Then, no matter how things turned out, I would at least know I had done my level best with the information in front of me.

RC has four social rules. They help create a friendly, intellectual environment where you can spend as much of your energy as possible on programming.

The social rules are:

• No well-actually’s
• No feigned surprise
• No backseat driving
• No subtle -isms

One thing that often confuses people about the social rules is that we expect people to break them from time to time. This means they’re different and totally separate from our code of conduct.

McLaren Stanley:

Alright folks, gather round and let me tell you the story of (almost) the biggest engineering disaster I’ve ever had the misfortune of being involved in. It’s a tale of politics, architecture and the sunk cost fallacy

Ian Leslie:

Paul McCartney has been writing and performing music more or less continuously since 1956. That’s sixty-four years.

Kent C. Dodds:

1. Not everything in your application needs to be in a single state object. Keep things logically separated (user settings does not necessarily have to be in the same context as notifications). You will have multiple providers with this approach.
2. Not all of your context needs to be globally accessible! Keep state as close to where it’s needed as possible.

Vasco Figueira:

TL;DR “Microservices” was a good idea taken too far and applied too bluntly. The fix isn’t just to dial back the granularity knob but instead to 1) focus on the split-join criteria as opposed to size; and 2) differentiate between the project model and the deployment model when applying them.

…

There are build patterns that give us total control over the relative visibility between components and over how they compose into deployables. One build to many deployables, many to one or anything in between is possible. Shifting concerns left helps us build better software. An earlier error is a better error. Constraints liberate.

The tensions and constraints that shape the arrangement of our projects, modules and dependencies are of a different nature than those shaping the arrangement of our deployables. A little build-fu goes a long way in combining development friendliness with mechanical sympathy.

My system for processing email is similar to Xavier’s.

Though, I use the Things Helper app to add links to emails directly to my Things inbox.

Paul Ollinger:

Danish values also provide a three-step prescription to turn the day around: “In Denmark, we have sort of a mental health [checklist]: Do something active. Do something together with other people. Do something meaningful.”

Great scientists tolerate ambiguity very well. They believe the theory enough to go ahead; they doubt it enough to notice the errors and faults so they can step forward and create the new replacement theory. If you believe too much you’ll never notice the flaws; if you doubt too much you won’t get started.

Dan Abel:

Feedback is someone is trying to help. Listen. Then ask questions - to gain understanding of their point of view.

I also enjoyed the idea of treating Slack more like Twitter.

Peter Naur’s classic 1985 essay “Programming as Theory Building” argues that a program is not its source code. A program is a shared mental construct (he uses the word theory) that lives in the minds of the people who work on it. If you lose the people, you lose the program. The code is merely a written representation of the program, and it’s lossy, so you can’t reconstruct a program from its code.

A copy of the paper.

Ken Kocienda tells stories of how Apple built the iPhone and iPad: a small team (less than twenty people) charged with delivering on direction set by executives.

Part one:

• Viewing product development decisions as economic tradeoffs.
• Shifting from deterministic planning models to a stochastic perspective.
• Managing the Fuzzy Front End: the time from opportunity identification to commitment.

Part two:

• Assessing the reserve buoyancy of a project.
• Using loss of safety margin as a leading indicator of project deterioration.
• Becoming more rigorous about how we think about technical debt.

John O’Shea:

Dashboards are the human-facing views into our systems that provide concise summaries of how the system is behaving by displaying time series metrics, logs, traces, and alarms data.

A look at how Amazon do dashboards.

Jeff Hodges:

Below is a list of some lessons I’ve learned as a distributed systems engineer that are worth being told to a new engineer. Some are subtle, and some are surprising, but none are controversial.