I had a conversation recently involving contract testing between partners. The provider provides the contract during their ci/cd process before the deployment. The consumer will validate it and if something fails, the change is rejected and the deployment never occurs. The concept of consumers signing off and blocking deployments is very interesting as it empowers and handles the control to the consumer.

It is much easier to imagine negative consequences than the positive possibilities of a change. Humans are wired to first think about the risks as a survival trait.

Progress begets progress, which is why celebrating milestones and team culture in the form of stories and surprises that become folklore are critical. This is the stuff that keeps a team together long enough to figure it out. Without these elements of adventure, building a company or any other bold project feels like you’re on a treadmill and will be harder. https://www.linkedin.com/pulse/10-thoughts-running-leading-teams-building-products-scott-belsky/?trackingId=8qfNtJKfSI%2BhaJO9%2BNLhmg%3D%3D

Use autoscaling for traffic spikes design for scalability from the start plan for and implement fault tolerance prioritize horizontal scaling for scalability implement data partitioning and sharding use data lakes for analytics and reporting employ CDNs for global latency reduction make operations idempotent for simplicity use event-driven architecture for flexibility employ blob/object storage for media files embrace tradeoffs; perfection is unattainable implement Data Replication and Redundancy Implement rate Limiting for system protection use a read-through cache for read-heavy apps utilize write-through cache for write-heavy apps opt for NoSQL Databases for unstructured data use Heartbeat Mechanisms for failure detection adopt WebSockets for real-time communication employ Database Sharding for horizontal scaling clearly define system use cases and constraints consider microservices for flexibility and scalability design for flexibility; expect requirements to evolve utilize Database Indexing for efficient data retrieval understand requirements thoroughly before designing Utilize asynchronous processing for background tasks consider denormalizing databases for read-heavy tasks avoid over-engineering; add functionality only as needed prefer SQL Databases for structured data and transactions use Load Balancers for high availability and traffic distribution consider message queues for asynchronous communication

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.