talk I’ve wanted to give since noticing a lot of what core services did while I ran it was dictated by fear (mostly of BDB/partie)…it struck me that fear caused a lot of unnecessary paralysis, which could be avoided if we considered how to confront fear in software development
Also easier to induce in the laboratory…a phenomenon is known as preparedness. Because early humans that were quick to fear dangerous situations were more likely to survive and reproduce, preparedness is theorized to be a genetic effect that is the result of natural selection.
like fear, elicit a stronger reaction and are more contagious than positive emotions…in larger organizations it’s like trying to stop the flu from making the rounds at the office
dark • you can be scared of the bogeyman • if you fear both…how does the bogeyman in the dark make you feel? you’re afraid of sharks…you’re afraid of water…SHARKS IN THE WATER…FUCK THE BEACH! you’re afraid of dogs…you’re afraid of spiders…DOGS WITH 8 LEGS!
here databases are terrifying…they’re complicated and we call on them to store things that would put us out of business if we lost them…we put them on pedestals, believe only experts can build them ! I fear other things as well, but my experience working on partie developed most of my thoughts around fear and software development
the most attention Fear will keep you from improving things…"that shit's scary, DON'T GO IN THERE!" feedie’s data model workfeed’s data model artie’s ability to DDoS the site
was the best tested code in the company a broken test is cheap and won't hurt anyone/anything most importantly, I had a series of tests that broke BDB every way I could…tests verified that BDB behaved how I expected and that partie could at least identify the failure and potentially fix it
in every way I could conceive before it left my computer…and then I put it back together reduce things to a smaller stage…it’s learning on the practice field vs. learning in Yankee Stadium make a mistake in Yankee Stadium and get sent back to the minors…make a mistake on the practice field and you do the drill 10 more times
to the old postgresql messaging db while also writing to feedie we slowly increased read traffic to feedie, switching it back when problems arose durable queues meant we could take feedie down entirely without losing deliveries even after switching to 100% reads on feedie, we kept double dispatching for months because we could
get under that hood and start yanking cables…is it as bad as we've made it out to be? best case…it's not bad and we can ship whatever you do worst case…it's bad, but now we know a lot more about the bad