Read on Twitter
here's a shiny piece by @JpottsNyc with lots of hard-fought wisdom on simplifying unnecessarily complex architectures. 
https://medium.com/@sre_by_day/simplifying-complexity-plagued-architectures-7000569f7a7e
https://medium.com/@sre_by_day/simplifying-complexity-plagued-architectures-7000569f7a7e
note that these are the kinds of problems you have to look forward to if you get most of the big things *right* -- engineering autonomy, product, growth. if you have these problems, you're doing many things well.
we tend to think of pain as a bad thing. but in the immortal words of the Dread Pirate Roberts: life is pain. growth is pain. it's a tool.
all you can do is pick your battles, and try to minimize the pain that is disproportionate, unproductive, or just plain pointless.
all you can do is pick your battles, and try to minimize the pain that is disproportionate, unproductive, or just plain pointless.
the pain of getting paged is frustrating and pointless unless it is connected to someone who can transform that pain into fixing the problem.
that same alert might be a gift to an engineer who is trying vainly to hunt down a complex systems interaction causing payments to fail.
that same alert might be a gift to an engineer who is trying vainly to hunt down a complex systems interaction causing payments to fail.
reading this blog post, you can spot a bunch of smart adaptive strategies:
- a platform team of experienced generalists
- autonomy for individual teams to DTRT
- centralization around storage conventions
- teams focus on shipping product
- healthy suspicion of grand changes
- a platform team of experienced generalists
- autonomy for individual teams to DTRT
- centralization around storage conventions
- teams focus on shipping product
- healthy suspicion of grand changes
change is costly, in and of itself. if you're doing something that works, keep doing it until it stops working.
my rule of thumb is 10x. unless or until you're convinced that the replacement is 10x better than what you're doing now, it's not worth the price of change.
my rule of thumb is 10x. unless or until you're convinced that the replacement is 10x better than what you're doing now, it's not worth the price of change.
that said, everything eventually fails. (*everything*) 
it's interesting -- this piece was written by someone working as a VP. i don't know many VP eng who could write and argue for such a cogent and detailed architecture plan.
it's interesting -- this piece was written by someone working as a VP. i don't know many VP eng who could write and argue for such a cogent and detailed architecture plan.
i feel like this is an artifact of the way that we try to force senior people into the technical track or the people track. if you switch back and forth you sacrifice your "career gains". 
i think the shortsightedness of this is becoming increasingly clear to people.
i think the shortsightedness of this is becoming increasingly clear to people.
if sociotechnical problems have sociotechnical solutions, then it seems like we should be nurturing technical leaders who don't see the solutions through purely a technical lens or a people lens.
i'm not sure how that intersects with job ladders, but ÂŻ\\_(ă)_/ÂŻ tbdig
i'm not sure how that intersects with job ladders, but ÂŻ\\_(ă)_/ÂŻ tbdig
