1. Review your own code first
2. Write a clear changelist description
3. Automate the easy stuff
4. Answer questions with the code itself
5. Narrowly scope changes
6. Separate functional and non-functional changes
7. Break up large changelists
8. Respond graciously to critiques
9. Be patient when your reviewer is wrong
10. Communicate your responses explicitly
11. Artfully solicit missing information
12. Award all ties to your reviewer
13. Minimize lag between rounds of review

- Let computers do the boring parts
- Settle style arguments with a style guide
- Start reviewing immediately
- Start high level and work your way down
- Be generous with code examples
- Never say “you”
- Frame feedback as requests, not commands
- Tie notes to principles, not opinions
- Aim to bring the code up a letter grade or two
- Limit feedback on repeated patterns
- Respect the scope of the review
- Look for opportunities to split up large reviews
- Offer sincere praise
- Grant approval when remaining fixes are trivial
- Handle stalemates proactively

In this course, we are focusing on building strong foundational skills. The course is structured in a way to provide more real life examples and how learning each of these topics can play an important role in day to day SRE life.

We prepared a dataset from the GH Archive that contains all the events in all GitHub repositories since 2011 in structured format. The dataset was uploaded into ClickHouse, where it contains 3.1 billion records. We redistribute it for research purposes and it can be downloaded at this direct link. This dataset can help answer almost any question about GitHub that you can imagine.

This article shows the usage of the dataset and offers insights into the GitHub ecosystem. It emphasizes how easy it is to play with data using modern tools.

k6 is a modern load testing tool, building on Load Impact's years of experience in the load and performance testing industry. It provides a clean, approachable scripting API, local and cloud execution, and flexible configuration.

The example case is simple: Deploy a minimal REST API and evolve its code from the easiest (read: ugliest) to the what we think is production ready.

- Don’t assign blame
- Do take responsibility
- Don’t procrastinate
- Do gather information
- Don’t be vague
- Do define clear owners
- Don’t lose focus
- Do use a consistent template

Karpenter is a metrics-driven autoscaler built for Kubernetes and can run in any Kubernetes cluster anywhere. It's performant, extensible, and can autoscale anything that implements the Kubernetes scale subresource.

A service health dashboard in Go that is meant to be used as a docker image with a custom configuration file.