-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
51 changed files
with
455 additions
and
91 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,24 @@ | ||
# Black coffee | ||
#publish | ||
Opened [[2024-11-11]]. Related to [[Musings on everything else]]. Actually unrelated to [[Coffee]]. | ||
|
||
## Background | ||
When you _really_ like coffee, you start drinking it black -- because you appreciate the coffee more, not the additives. | ||
|
||
I feel like that's a universal behavior of most hobbies. Here, I'll document the interesting "black coffees" of various hobbies I've encountered. | ||
|
||
|
||
## Blends | ||
**Drumming**: [Arrakis (Noisia remix)](https://youtu.be/x7mADamRuRI) | ||
- Black coffee for drummers | ||
- Basically just layers of drums instead of a traditional melody-harmony | ||
|
||
**Photography**: (Some incredibly fancy camera. Just an example) | ||
- Means nothing to the average person | ||
- Means everything to an experienced photographer | ||
|
||
**Digital art**: Custom brushes, like [[My Procreate brushes]] | ||
- At least to me, "black coffee" brushes are ultra simple brushes that can be used for everything from lineart to shading and blending | ||
- I prefer PC-based blending algorithms (PCs offer a higher draw rate and therefore smoother blends) but Procreate offers something similar with the super simple dry brush in this pack. That's kind of like black coffee to me -- having the right blending algorithm means a lot | ||
|
||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,60 @@ | ||
# Blameless postmortems | ||
#publish | ||
Opened [[2025-01-01]]. From [[Musings on tech]]. | ||
|
||
I've worked on 3 separate Google SRE teams since joining in 2020. One thing I see the SRE org execute on really well is blameless postmortems. In other words, a [[Technical postmortems|postmortem]] where there's no finger-pointing at individuals, and instead a focused effort to improve the lapse in process that caused something to break. | ||
|
||
Google's popular SRE book has an excellent [section](https://sre.google/workbook/postmortem-culture#model-and-enforce-blameless-behavior) explaining how to write blameless postmortems. But it skimps a bit explaining _why_ you should want to write them in the first place, so I'm here to babble about that topic. | ||
|
||
## Why you should virtually always prefer a blameless postmortem | ||
|
||
### The obvious reasons | ||
It's polite, and healthier for group morale. Higher morale leads to all sorts of positive emergent culture patterns: | ||
1) People feel comfortable communicating bad news to leadership early, without fear of retaliation. | ||
2) Developer velocity improves, because engineers feel more protected taking (healthy) risks. | ||
3) Everyone's happier. | ||
|
||
And besides, it's nice to not point fingers. Nobody enjoys a meeting where one person gets chastised on front of everyone for their mistake -- not the audience, nor the presenter, nor the chastisee. | ||
|
||
### Less obvious reasons you should want blameless postmortems | ||
Acting blamelessly lets you review your _processes_ with much more effective scrutiny than if you'd attributed an outage to a human. | ||
|
||
The larger insight I'm ramping up to is that _blameless postmortems rarely work in the long term anyways_ -- blaming humans for outages typically ends up being a band-aid fix that only lasts until someone forgets. Lurking below most human errors is typically a complicated process-based problem. | ||
|
||
Blaming a human ensures: | ||
|
||
- That person won't repeat their mistake. | ||
|
||
... and that's about it. If you're lucky enough that everyone on your team reads your postmortem, and it strikes the fear of _((deity))_ in their hearts, nobody else will repeat that mistake either. For a while. Until they forget, or you hire someone new, or an opaque technical change happens, etc. ... | ||
|
||
Whereas blaming a process (and then improving the process) ensures: | ||
|
||
- That category of mistake won't happen again, at least not in that same way. | ||
|
||
Improving a process typically costs more effort in the short term than blaming a human. Even the exercise of determining what may be improved can require input from technical stakeholders whose time is valuable. Improvements also cost SWE-time to implement, so you may find yourself making tough tradeoffs between moving fast and breaking things, versus prioritizing a process improvement in order to prevent breaking things. Choosing what to prioritize is difficult, and best decided via either well-sharpened intuition (for teams in scrappy situations) or an organic checks-and-balances culture between developers and DevOps engineers who can suggest how to manage their own time. (This culture is also easier to cultivate when issues are blameless, and stakeholders can voice their honest opinions.) | ||
|
||
Anyways, even if your team doesn't have the bandwidth to deliver large improvements, it's still a useful exercise to brainstorm how you might do it -- blamelessly. | ||
|
||
Don't trick yourself into believing that blaming the person who triggered an outage will prevent that outage from happening again. Best case scenario: it doesn't, only for a little while. | ||
|
||
## The bottom line | ||
Blame processes, not people. | ||
|
||
## Appendix | ||
### On laziness causing outages | ||
Outages are bad and lazy actions often cause outages. Therefore, it can be tempting to assume that the root cause of certain outages is pure laziness, especially if it seems like laziness: | ||
|
||
> For example: Person X forgot to run unit tests, even though the launch documentation clearly told them to. | ||
Even in cases where human carelessness seems to be the issue: dig deeper. Don't give into the thought pattern that you're seeing the real issue. If people can forget once, they can forget again, especially as your team scales larger or its workload increases. (Separately: one-off mistakes are a very biased metric to measure someone's performance by. It's possible Person X's project is riskier than others', for example). | ||
|
||
It's better to brainstorm deeply about what can be improved. Anything from updating an internal wiki page, to making tests automatic, to rewriting something more serious. You don't need to necessarily do these things. But surveying your options is good and helps keep the team aware that they can influence the processes they use. This is actually especially true if Person X happens to be lazy -- you should configure processes that don't allow laziness to cause outages. | ||
|
||
One last note on laziness. I like the quote: | ||
|
||
> "You do not rise to the level of your goals. You fall to the level of your systems." | ||
### On postmortem culture being "professional" and war room comms being "unprofessional" | ||
Redacting names from a postmortem is typically good, since it's [not process-relevant](https://sre.google/workbook/postmortem-culture#counterproductive-finger-pointing) who broke something. | ||
|
||
Redacting names in a war room is... doable, but probably unproductive. Remember: what you really want is to nurture a culture where people feel comfortable chirping up that their code _might_ be the culprit of an outage. Typically when people are confident their code is broken, they'll speak up -- but your job as an incident commander and postmortem steward is to make folks feel comfortable speaking up before they're confident. This lets you get experienced eyes on a pull request, and mitigate outages quicker. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,24 @@ | ||
# Cafe Reveille | ||
#publish | ||
_Part of a series on [[The best burger in the bay area]]._ | ||
|
||
Visited [[2024-11-03]] for brunch with Christie. | ||
|
||
![[PXL_20241103_175730484.MP.jpg]] | ||
_A bit generic looking_ | ||
|
||
The good: | ||
- It's not drenched in oil nor too heavy | ||
- The ketchup (not part of the burger rating is good and seemingly house made) | ||
|
||
The ehs: | ||
- Generic everything | ||
- Cheddar cheese | ||
- Vaguely chilly vegetables | ||
- Patties cooked all the way through with no pink | ||
|
||
5/10, 0/10 for unusualness. It's like a generic backyard BBQ burger with the full amount of fix-ins. | ||
|
||
Meta comment: [[My food rating system]] decrees that I don't rate something as average and pick whether it's a little above or below. This felt perfectly average but on principle I'm rating it down -- it wasn't super remarkable. | ||
|
||
Also worth noting: This place is a cafe and not really known for their burgers. They have a delicious looking poppy seed bun used for their breakfast sandwiches; idk why they didn't reuse it on their burgers. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,30 @@ | ||
--- | ||
aliases: California license plates | ||
--- | ||
# California car names | ||
#publish | ||
Opened [[2024-11-14]]. From [[Musings on everything else]]. | ||
|
||
There's a common pattern in California license plates. Their first character is typically 1 number (usually 7, 8, 9), followed by 3 letters, followed by 3 numbers. For example: 9ABC123. | ||
|
||
Not all plates are like this. But I notice cars like this _so_ often that I've made a game out of it: the 3 letters sandwiched in the middle of the plate is the car's name! | ||
|
||
For example, meet Fenix: | ||
![[PXL_20240924_155145570.MP.jpg]] | ||
_"Vroom" says Fenix._ | ||
|
||
Deanna: | ||
![[Pasted image 20250105134156.png]] | ||
|
||
Hero: | ||
![[Pasted image 20241227134710.png]] | ||
|
||
Jay Peg: | ||
![[Pasted image 20241227134729.png]] | ||
|
||
Rubolf (sometimes making a name is hard): | ||
![[PXL_20241219_010647518.MP.jpg]] | ||
|
||
And my favorite plate yet. Carlos! | ||
![[Pasted image 20250105134530.png]] | ||
_His friends call him "Car"_ |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
# Coffee | ||
#publish | ||
#needswork | ||
Opened [[2024-12-30]]. | ||
|
||
Unrelated to [[Black coffee]] (but I'll link it here for funsies). | ||
|
||
https://www.reddit.com/r/intermittentfasting/s/STDrdhtuan is a nice, no-BS explainer about why your coffee is bitter. | ||
|
||
TODO: Fill in this page with the how/what/why I like my coffee. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.