Nemawashi (根回し) in Japanese means an informal process of quietly laying the foundation for some proposed change or project, by talking to the people concerned, gathering support and feedback, and so forth Put more effort and time into searching for and involving people who either will have strong opinions about a large decision or will be affected by that large decision The Rule: anyone can make an architectural decision. The Qualifier: before making the decision, the decision-taker must consult two groups: The first is everyone who will be meaningfully affected by the decision.

Observability without action is just storage Too many people store terabytes of data and call it observability https://twitter.com/boristane/status/1783842355147325494?t=5OUgcOmHIcwbGqrdIjR1Hw&s=19

Lens 1: The person In what ways (if any) might the individual be contributing to the problem? (Things like their workstyle, lack of skill, motivation, clarity.) Lens 2: You In what ways (if any) might you be contributing to the problem? (Maybe you didn’t provide feedback, didn’t set clear expectations.) Lens 3: The team/ organisation In what ways (if any) might the team/organisation/systems be contributing to the problem? (Things like interdependencies, unclear processes, conflicting priorities.

Common mistakes that teams make when not thinking strategically: Focusing on the wrong priorities Focusing on the wrong outcome Not involving the right people at the right time Not seeing the bigger picture Not anticipating problems Not understanding how one project impacts another Working without thinking through why the work is being done Diving into work without thinking if it’s already been solved before Working and getting feedback only at completion (not earlier) Not converting ideas into action in efficient ways

Strengths of JSON Merge Patch: Easy for users to understand and implement. Naturally idempotent Well-defined semantics Robust to versioning Shortcomings of JSON Merge Patch Cumbersome to modify array values

REST means different things to different audiences. It means one thing to the developer completing their assignments in Jira, another to the engineering leader attempting to herd cats through a transformation, and yet another to the marketplace selling solutions. The term’s conflation isn’t an indictment of people’s laxness but an example of its success. We see this pattern repeatedly throughout the tech landscape. Agile methodologies, cloud computing, and even DevOps all started with specific principles but branched out, sometimes to their originator’s chagrin, as diverse groups adopted them.

Bad strategy ignores the power of choice and focus, trying instead to accommodate a multitude of conflicting demands and interests. Like a quarterback whose only advice to his teammates is “Let’s win,” bad strategy covers up its failure to guide by embracing the language of broad goals, ambition, vision, and values. As seen in: https://www.mckinsey.com/capabilities/strategy-and-corporate-finance/our-insights/the-perils-of-bad-strategy

GraphQL has an advantage over simple Web APIs, as it offers some insight into how many users are using each field of your API. Although this insight may not be completely accurate, it can still be useful in estimating the cost of making a breaking change in a specific field. With this information, you can communicate the potential impact of the change more effectively.

What is an API design specification? A collection of patterns (with examples) Rules about how to apply them Tests to automate compliance

Soft skills dominate hard skills. Many hard skills will be automated by AI anyway. Soft skills and human relationships are the future, and emotional intelligence can be learned.