Bytes that get stuck in your teeth.
Think of me as a web crawler with taste.
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:
- 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.
- 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.
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.
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.
161 suggestions from the staff at Automattic.
Trade offs and spooky stories from Stefan Tilkov.