Quartz sync: Jan 11, 2025, 11:21 AM

content/Articles I like.md

@@ -11,6 +11,8 @@ Opened [[2023-12-07]] but I should have done it way sooner. Related to [[Poetry
 - [Your Real Biological Clock Is You’re Going to Die](https://hmmdaily.com/2018/10/18/your-real-biological-clock-is-youre-going-to-die/) - Bit of a morbid topic but an excellent reframing of what it means to be a parent and how one should measure their time left on Earth
 - https://www.newyorker.com/news/news-desk/curiosity-and-the-prisoner - Commencement speech about curiosity and what equality really means
 - [ACX: The Far Out Initiative](https://www.astralcodexten.com/p/profile-the-far-out-initiative) - Related to the [[The Sinusoid]]. Scott analyses the Far Out Initiative.
+- https://blogs.cornell.edu/info2040/2015/10/14/the-evaporative-cooling-effect-in-social-network/ - 2010 essay popularizing Eliezer Yudowsky's "Evaporative Cooling" term to describe what causes (and mitigates) the death of social networks. Originally written to critique Quora, which has indeed evaporated in just a few short years after this essay, it holds relevance to any tech founder starting a social network business.
+    - If the [link](http://blog.bumblebeelabs.com/social-software-sundays-2-the-evaporative-cooling-effect/) in the article doesn't work, try this web archive [link](https://web.archive.org/web/20101012105003/http://blog.bumblebeelabs.com/social-software-sundays-2-the-evaporative-cooling-effect/)
 
 ### Just for fun
 - [How to be a -10x Engineer](https://taylor.town/-10x)
@@ -22,6 +24,7 @@ Opened [[2023-12-07]] but I should have done it way sooner. Related to [[Poetry
 - [Brian Balkus obo Palladium: The Mineral Crisis is here](https://www.palladiummag.com/2022/08/08/the-mineral-conflict-is-here/)
 - [Pundit's Fallacy - the best definition](https://www.jargondatabase.com/Category/Other/Logical-Fallacies-Jargon/Pundit's-Fallacy)
 - https://www.plasticlist.org/report - 6 month long and $500k research investigation into the presence of plastic chemicals in everyday food. Turns out to be a rabbit hole and way more than you wanted to know about the current state of scientific research into safe dosages of plastic chemicals.
+- https://www.erichgrunewald.com/posts/not-a-meat-eater-faq/ - balanced take on vegetarianism, written by an omnivore-sympathetic vegetarian
 
 ### Regarding career
 - [How to communicate when trust is low (without digging yourself into a deeper hole)](https://charity.wtf/2023/08/17/how-to-communicate-when-trust-is-low-without-digging-yourself-into-a-deeper-hole)
@@ -41,4 +44,13 @@ _Nothing special, I just don't want to forget these exist._
 - [https://soranews24.com/2022/06/23/is-roughly-half-of-japan-preconditioned-to-hate-mint-chocolate-sweets/](https://soranews24.com/2022/06/23/is-roughly-half-of-japan-preconditioned-to-hate-mint-chocolate-sweets/) fascinating and hella specific article about Japanese preferences for mint chocolate chip ice cream where a city had 10% fondness for it. Relevant to [[Nature vs nurture]]
 
 ## Appendix
+### Misc
 This page is sort of related to [[Internet roasts]].
+
+### Article sources
+Generally speaking, I've had good experiences with:
+- msci.com
+- pew research
+- axios for current affairs
+- The ones I linked from within [[Rationalism]]
+- YouTube documentaries

content/Blameless postmortems.md

@@ -4,57 +4,59 @@ 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.
+Google's popular SRE book has an excellent [section](https://sre.google/workbook/postmortem-culture#model-and-enforce-blameless-behavior) explaining how to write these. But IMO it skimps on explaining _why_ you should want to write them in the first place, so I'm here to babble about that.
 
 ## 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:
+It's 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.
+And besides, it's nice to not point fingers. Nobody enjoys a meeting where one person gets chastised on front of their peers -- not their peers, 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. 
+Acting blamelessly lets you review your processes with more effective scrutiny than had you 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.
+The larger insight I'm ramping up to is that _blameless postmortems rarely work in the long term anyways_ -- blaming humans for outages typically results in band-aid fixes that only work until one person forgets about them. Lurking beneath a human-based _trigger_ is typically a complicated process-based _root cause_.
 
-Blaming a human ensures:
+To hammer this home -- 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:
+Whereas blaming a process (and then improving said process) ensures:
 
-- That category of mistake won't happen again, at least not in that same way.
+- That category of mistake won't happen again.
 
-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.)
+Unfortunately, the drawback here is that improving a process typically costs more effort in the short term than blaming a human. Even the exercise of determining what process to improve may 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 shipping fast and breaking things, versus investing in reliability in order to prevent breaking things. Choosing which to prioritize is difficult, and best decided via either well-sharpened intuition (for teams in scrappy situations) or a checks-and-balances culture between developers and DevOps engineers who can suggest how to manage their own time (for teams in less scrappy situations -- also worth noting that this culture is 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.
+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.
 
+## The bottom line
 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.
+Instead: 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:
+Outages are bad, and lazy actions often cause outages, so it can be tempting to assume that the root cause of an outage is pure laziness. This is especially true 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).
+Even in cases where human carelessness seems to be the issue: dig deeper. A lazy human might have been the _trigger_, yes, but what was the underlying cause? If a human can forget once, they can forget again, especially as your team scales in size or workload.
+
+(Separately: one-off mistakes are a very biased metric to measure someone's performance. It's possible Person X is simply working on a riskier project).
 
-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.
+In scenarios with a human trigger, it's still better to dig into what process can be improved. Anything from updating an internal wiki page, to making tests automatic, to rewriting something more serious. Even if you don't implement these changes, brainstorming them allows you to learn the developer-agnostic cost of reliability, that is, the cost of reliability that doesn't live only in your current teammates' brains. Developers aren't fungible -- firing one and hiring another doesn't mean their shoes can be filled instantly -- so doing this exercise lets you understand where the reliability gaps are and make you more resilient to change.
 
 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 from a postmortem is typically good, since they [aren't relevant](https://sre.google/workbook/postmortem-culture#counterproductive-finger-pointing) to making future improvements to your processes.
 
-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.
+Redacting names in a live war room is... doable, but probably not worth it IMO. Remember: blamelessness is just a means to an end. The larger goal of blamelessness is nurturing a culture in which 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 a postmortem steward is to make folks feel comfortable speaking up _before they're confident_. This lets you gather more technical opinions faster, grease the wheels of conversation, and ultimately drive a faster fix.

content/Coffee.md

@@ -2,6 +2,7 @@
 #publish 
 #needswork
 Opened [[2024-12-30]].
+_Part of a series on [[Recipes]]._
 
 Unrelated to [[Black coffee]] (but I'll link it here for funsies).
 

content/Hazie's.md

@@ -0,0 +1,40 @@
+# Hazie's
+#publish 
+Opened [[2024-12-08]].
+
+_Part of a series on [[The best burger in the bay area]]._
+
+Fusion restaurant on Hayes Street. It's one block away from [[Chez Maman]]and two blocks away from [[Arbor]]! I visited here [[2024-12-08]] with Christie.
+
+![[Pasted image 20241209004632.png]]
+
+![[Pasted image 20241209004658.png]]
+
+In a nutshell: unexpectedly good burger! I came in with tempered expectations but enjoyed this. 6.5/10, maybe a 6.75 if I were splitting ratings that finely.
+
+Things I liked:
+- Flavor palette here is uncommon as compared to other burgers and works well. There's a nice mix of acidity and savory
+    - Pickles provide essential acidity
+    - A hint of umami here too. I'll get mushrooms next time to lean further into that flavor; I think it would benefit a lot from it.
+- Doesn't drip oil at all. And the bun is nice and dry.
+
+Things that were just OK:
+- Bun is crackly and light.
+    - It's not amazing but better than I'd expected based on appearance.
+- Not much lettuce. The texture would have benefitted from more
+
+Things I didn't quite like:
+- Meat is cooked too much. It's not medium rare.
+    - Honestly this is what holds the burger back the most. When I compare mentally to [[Chez Maman]], this burger actually does much more than Chez Maman's. But Chez Maman excels with the patty meat so much more than Hazie's that I can't help but rate it lower.
+
+Unusualness factor is 0.5. Calculation:
+- Normal (+0)
+    - Bun
+    - Beef
+    - White cheddar
+    - Tomato
+    - Pickle
+    - Lettuce
+- Unusual-ish (+0.25 each)
+    - Caramelized onions
+    - Relish aioli

content/Musings on everything else.md

@@ -46,3 +46,6 @@ Misc notes
 - [[The fitness enthusiast's guide to eating out in SF]]
 - [[Hysteresis]]
 - [[A causal test of the strength of weak ties]]
+
+## Miscategorized (TODO: move these elsewhere)
+- [[Recipes]]

content/Musings.md

@@ -9,10 +9,3 @@ This is a meta page to link to my other musings.
 - [[Musings on myself]] (private)
 
 TODO: group these all under a note called [[Teaching to avoid learning]]
-
-Generally speaking, the stuff that sparks my brain:
-- msci.com
-- pew research
-- axios for current affairs
-- The ones I linked from within [[Rationalism]]
-- YouTube documentaries

content/Pancakes.md

@@ -0,0 +1,27 @@
+# Pancakes
+#publish 
+Opened [[2025-01-11]].
+_Part of a series on [[Recipes]]._
+
+![[Pasted image 20250111093043.png]]
+
+## What is it
+Unusually fluffy American pancakes. When cooked correctly they have a flaky texture that's almost croissant-like.
+
+## Ingredients
+- 1 egg
+- 1 cup flour
+- 1 cup buttermilk
+- 1 tsp baking soda
+- 1/2 tsp salt
+- (optional -- if you want it sweeter) 1 tablespoon sugar
+
+## Prep
+Mix ingredients in a bowl.
+
+Cook pancakes on a griddle at medium-high heat.
+
+## Postamble
+This recipe comes from a late family friend, Mark. He optimized his pancakes for fluffiness.
+
+I'm not typically a pancake enjoyer, but I like these.

content/Pīrāgi.md

@@ -1,12 +1,21 @@
 # Pīrāgi
 #publish 
 #needswork - get Mom's recipe and add pics
-Opened [[2024-01-07]]. Part of a series on [[Recipes]]. Ha ha. One day I'll start that series.
+Opened [[2024-01-07]].
+_Part of a series on [[Recipes]]._
 
-TODO: pics
+TODO: pic
+
+## What is it
+Pīrāgi is a Latvian dish I grew up making for special occasions. It's a lot like a Polish pierogi, but with meat. It's basically a baked dumpling.
 
 ## Ingredients
 Todo.
 
-## Recipe
-Todo.
+## Prep
+Todo.
+
+## Postamble
+This recipe is my mother's modified recipe.
+
+Todo.

content/Recipes.md

@@ -0,0 +1,10 @@
+# Recipes
+#publish 
+Opened [[2025-01-11]]. Linked from [[Musings on everything else]], although it should be categorized somewhere else eventually.
+
+Written
+- [[Pancakes]]
+
+Unwritten
+- [[Pīrāgi]]
+- [[Coffee]]

content/The best burger in the bay area.md

@@ -30,9 +30,7 @@ Related to [[Warren's long burgers]].
 | [[Chez Maman]]                    | 7/10               | 1                      | $22       |
 | [[Arbor]]                         | 5/10               | 0.25                   | $17       |
 | [[Cafe Reveille]]                 | 5/10               | 0                      | $17       |
-[[Hazie's]]
-
-https://sfstandard.com/2024/09/30/best-burgers-san-francisco/ has a neat bucket list
+| [[Hazie's]]                       | 6.5/10             | 0.5                   | $24       |
 
 ## Philosophy behind these ratings
 It's hard to rate a burger definitively "X/10" because burgers have a wide variety of ingredients and degrees of fanciness - you're often not comparing the same type of burger to the next.
@@ -54,6 +52,8 @@ Example rating from the [[Spruce]] review:
 ## Appendix
 Burger-related but I haven't written about yet: [[Warren's long burgers]]
 
+https://sfstandard.com/2024/09/30/best-burgers-san-francisco/ has a neat bucket list
+
 Found [[2023-04-30]]: [The best SF burgers, according to /r/AskSF](https://www.reddit.com/r/AskSF/comments/1341txx/best_burger_in_san_francisco/)
 
 [[2024-12-15]]: New list to visit: https://www.theinfatuation.com/san-francisco/guides/best-burgers-san-francisco