A reasonable take to unpack and nuance uptime so that it leaves the realm of engineering and becomes a business decision as it should be.
Also good for engineering organizations to remember that: 1. You’re not Google. 2. Most of the practices in the SRE book are not applicable to you.
The post makes it look simple but pulling off a database migration project like this is very difficult to get right and incredibly costly in terms of time and attention that it requires.
A handy overview of how to hire for developer tooling and how to improve the developer experience at companies from a perspective that recognizes these are socio-technical issues but also needs to get stuff done.
What you’re looking for, I think, is someone who can take “developer experience” and push that forward holistically by whatever way is necessary. The hardest things they will have to do is gain the trust of the entire engineering organization, buy-in for their approach, and deliver perceived value and improvements.
This role is truly a Sociotechnical Engineer, in every sense of the term; they will expose the weaknesses of your company in ways you are not prepared for, and they will challenge the status quo in ways that are painful. Embrace it. Be prepared to grow as much, if not more, than they do.
“ChatGPT is fast-tracking the commodification of the human spirit by mechanising the imagination.”
Nick Cave’s rebuttal of AI is more than deserved after we had to sit through months and months of ridiculous self-serving hype pushed out by idiots.
Wat Sinan hier schrijft is een herkenbare spagaat voor iedereen die tussen meerdere culturen opgroeit. Om zijn eindvraag te beantwoorden: “Er is nergens om heen te rennen. De enige naar wie je toe kunt dat ben jezelf.”
I prefer to use contributing factors over the concept of a “root cause” and if people believe an incident has a single cause, usually that also means that they’re not very serious about reliability engineering.
We’re seeing a bunch of these posts come around serverless around the time that we too are reconsidering our investment in this area. Lambda has a lot of operational benefits but at larger scales the developer experience just does not keep up.
A long post that builds up to async Rust from the ground up and explains how the various bits and pieces work. Really quite the tour de force with a simple conclusion: use Tokio.
With our re-evaluation of Lambda as a platform and after talking to some people, I’d say that Rust is the most (maybe the only) viable language on Lambda mostly because it’s negligible cold start times, high performance and the amazing developer experience of