• Services meshes should provide reliability (retries, timeouts, traffic shifting, rate limiting), observability (error tracking, request volume, other logs), and security (mutual TLS, access control, etc.)
• Common feature set to avoid the need to implement in the application level within individual services. Uniform across stack in a way that's agnostic to the stack's implementation. Decoupled from business logic / application code as a whole. Avoids issues like thundering herd due to different services all implementing their own retry logic.
• Also organizationally decouples platform and service owners. We all know how tricky it is to properly implement retrying at the app level -- it's great if the underlying infra gave that for free. Rather than get every service owner to implement error logging / retries / TLS, lift that responsibility out.
• Note that due to this decoupling, certain things remain the application's responsibility. Things like tracing, responding to errors, preventing IDOR happens within application code. Some things are infra concerns but are not handled by the service mesh, like data encryption at rest, data replication, log aggregation.
• Ancestor of service mesh was an application-level shared RPC library that was culturally enforced ("fat client" library). E.g. Google Stubby. These were generally not stack independent and were opinionated re: programming model, and might contain business logic (e.g. middleware). Also similar to a decoupled service bus (which was generally a monolithic communication bus).
• Necessity / popularity / viability of service mesh tied to reduction in cost of microservice architecture. Today we have more infra and more operational experience. Also trends in containerization and other related tooling make handling microservices easier. Trend towards reducing downside of polyglot systems.

  • Docker: package any system into a portable black box.
  • Commoditized cloud infra: elastic access to compute.
  • K8s: Map packages to compute; operational cost of running 10 things isn't much different than 100.
  • Service mesh: proxy in front of each of the black box service packages providing uniform platform behavior.

• Multiple layers -- SQL layer (SQL -> KV lookup instructions), KV layer (HA node storage, with transaction / distribution layer)
• Multi-tenant architecture keeps SQL layer single-tenant but makes KV layer multi-tenant

  • SQL layer prefixes key with unique single-tenant identifier; KV layer does authN (what's the impact on perf?)
• Range rebalance, hot/cold mgmt are still done? This means that other tenant usage patterns may affect your perf?

  • Throttles to avoid one tenant dominating node resources...
• Ultimately their free offering is enabled by efficient packing of small tenants, such that the overhead of each tenant is effectively zero

• Money. The EV of startup equity is horrible, to the point where, by one estimate, you have less than 1% odds at out-earning what you would have made at a mega-corp.

  • What's misunderstood: the notion that startups are ALL cash-light and equity-heavy is outdated. Many "hot" startups these days pay competitive base salaries (well, at least up to the staff-ish level, where mega-corp salaries skyrocket to the realm of absurdity).
• Learning (in a vague sense). You will probably be exposed to more breadth at a startup, at a tradeoff of depth. I mentioned this when talking about growth potential and the difference between engineers from large and small companies, in the context of databases, architecture, and domain modeling.

  • What's misunderstood: the type of learning that's exclusive to startups is very narrow. (Valuable, but narrow.) Generally, working at a startup is invaluable for product learning, learning to work effectively cross-functionally, and learning to scale human elements like culture (NOT machine elements like databases).
• Impact. This is a question of definition. Yes, the final product will have more of your touch on it, but its reach and customer impact will likely be far smaller than if you worked at a megacorp. Comparing "increase performance by 10%" to "increase performance by 0.01%" is meaningless without considering total net impact (e.g., actual user base).

  • What's misunderstood: I think the part of impact that is more unique to startups is the cross-functional nature of it. It's much more likely that your work on a product touches areas outside your business function; for example, engineers at startups will very likely have a larger role in both design and product at a startup. Another, less sexy area where individuals have much more impact at startups is that individual bad decisions are much, MUCH more likely to straight up destroy the company at a startup.
• Interesting problems. Related to both the question of breadth / depth in "learning" and the question of definition in "impact." Startups generally don't have "basic research" projects concerning kernels, programming languages, cutting-edge computer science research, "innovation investments,"" etc. (startups like, say, CockroachDB are much rarer than yet another startup for your dog's mental health or something.) Things are generally much more procedural.

  • What's misunderstood: I think the "interesting problems" of startups are mostly product / business problems, not technical ones. Mega-corps are often happy to sit back and enjoy their massive second-mover advantage one some new product area is explored and proven, or to just throw money at buzzwords as hedges (hello, blockchain).
• Autonomy. At startups, you are usually at the whim of business requirements with regards to what you actually work on; you need to do what it takes for the business to succeed. There's less process, bureaucracy, and general large company insanity, but it's replaced by more danger and general small company insanity. And it's not like mega-corps are generally less flexible when it comes to quality of life things like remote work, either. People tout new-age remote-only startups, but it's easy to cherry pick -- my experience is that the average startup is much less remote-friendly than the average mega-corp, even with the remote-only outliers.

  • What's misunderstood: I think autonomy at startups is just overrated.

• I think the supposedly higher level of learning, impact, and amount of interesting problems at startup are generally constrained to the product space. If this is an area you are passionate about, it makes startups much more appealing.
• Regarding money: equity is overrated, while base salary doesn't get the attention it deserves. With that being said, it's almost guaranteed you'll make less at a startup than at a large company.
• I do think there is a kind of camaraderie that arises from startups that is hard to replicate at larger companies. But it's also the same kind of camaraderie that soldiers or sweat shop workers develop from living the same horrendous existence, so it's more of a silver lining on a crap situation than anything else.
• With all that said, I still consider my current job (at a startup) the best job I've had. I don't think it's due to any systemic difference between startups and large companies. I think I just got really, really, really damn lucky.

• ​Some reasons to work on productivity and velocity​
• ​95%-ile isn't that good​

Shoshin (初心) is a word from Zen Buddhism meaning "beginner's mind." It refers to having an attitude of openness, eagerness, and lack of preconceptions when studying a subject, even when studying at an advanced level, just as a beginner would.

• Teslas are common sights in plenty of places in the US now. But San Francisco remains the only place I've been where I've seen dirty Teslas. Everywhere else, Teslas are status symbols -- meticulously polished, a symbol of success. In San Francisco, Teslas are just cars with nice features.
• I've lived in San Francisco for about half a year, and visited maybe 5 times since I left. San Francisco has never smelled nicer than during lockdown.
• I can't believe some people actually dislike San Francisco fog. I was sorely disappointed when every day of my visit was bright and sunny. The fog is beautiful and the sun is the enemy.
• San Francisco has 179 playgrounds -- one of the most impressive collection in the US. I've always thought it was a terrible place for young kids, but I've been finding out that there are parts that are extremely nice.
• Everyone's heard of the Big Mac index. If there were an omakase index, you'd think San Francisco was downright cheap to live in. You get so much more for your dollar than pretty much anywhere in the East Coast (even in much cheaper cities). A dim sum index would also perform similarly, I think.

• ​The Phatic and the Anti-Inductive​

  • Captures much of my experience with therapists I assume are inexperienced. I've been lucky to be able to witness experts of cognitive behavioral therapy, and it's much, much better than the run-of-the-mill sounding board many therapists are. Also just a fun read, as always.
  • I got some additional insight from a psychiatrist friend that supportive therapy is really just the foundation of training, and is generally used when more specific therapies are ineffective due to severity of current symptoms or other factors. This explains a lot -- I'd assume that therapy from clinically practitioners has a higher level of rigor and structure.
• ​Stripe: Thinking Like a Civilization​

  • Lots of less interesting history here. One core insight is Patrick's remark on scaling the company: "When you come out of [the growth period where product development slows], if you do it well, then stand back." They recognized to persevere through the growing pains, and put the effort to build a culture (or civilization?) up front.
  • Callback to the idea of taste again. "While “taste” can be hard to define precisely, in some sense, whatever the domain — whether it’s music or something else — if you spend the time and you put a lot of thought into appreciating something, teasing apart what makes it great, and building a thoughtful, opinionated perspective, that’s taste."
  • On investing in potential future competitors: "As Stripe grows, we want to avoid the “we must win everything” mindset that can easily set in. We’d rather help enable a successful ecosystem… it’s a big, abundant world out there."
• ​The New Puritans​

  • Presented without comment.

1. 1.

   The strongest instinct God planted in Man was self-preservation (and not loving God, loving thy neighbor, etc.)
2. 2.

   Nature is harsh and cruel, and doesn't provide adequate means to fulfill God's commandment to "go forth and multiply."
3. 3.

   Thus, God intends for Man to labor and to create their own value. "Avarice is no longer a mortal sin, and there is nothing wrong with the infinite accumulation of wealth."

1. 1.

   The question of human nature is foundational, and unlike what Locke thinks, humans must pick sides, and thus establish friends and enemies. (The assumption seems to be that the question of human nature cannot be answered.)
2. 2.

   There will always be friends and enemies. Historically, those who refused to recognize anyone as enemies and pacifistically seek "unilateral disarmament" were destroyed (citing both the aristocracy in the Russian and French revolutions).
3. 3.

   Politics (and conflict) is thus unavoidable.

• The murder of Remus and the founding of Rome
• The Thirty Years' War and the Treaty (and Peace) of Westphalia
• (In Christianity) the murder of Christ itself, and the subsequent Christian world
• The (hypothetical) slaughter of Islam by Christianity or vice versa (hearkening back to Thiel's point that if the Wests responds to violence with violence, it loses differentiation with Islam).
• George Floyd and (hopefully) a world conscious of racial struggle and continued inequality
• (Maybe) the dot-com crash and the beginning of the modern tech industry (though many question if we've learned our lesson at all...)
• (Maybe) the crypto crash and end of the heady ICO days (same question)

The nature of Bloom’s thoughts on Communism (and relatedly Fascism) was quite subtle and sophisticated, of which there were three primary, intertwined concerns:

First, the nature of Communist society was inherently unjust and ineffectual, because it didn’t align with aspects of human nature foundational to society’s progress and ultimate happiness. Though one could argue or assume that everyone is created, in God or the laws’ eyes, equal, in actuality, there are differences in skills and talents that enable individuals to be better in certain instances than other individuals — better scientists, philosophers, musicians, basketball players, etc. Communism, by its very nature, would aim to minimize such naturally occurring differences, and consequently, prevent more talented individuals from reaching their potential and also benefiting society. As such, it was and is “unjust”. (Bloom’s interest in Plato’s Republic partly stemmed from its discussion of those inequalities’ potential benefits to society.)

Second, given that labor would not be paid on skill, capability or ostensibly even work for wages, people are not incentivized to work diligently. In one lecture, Bloom mentioned that when the Communists assumed power, food shortages (and consequent famine) ensued because the farmers stopped being productive: “They simply stopped working.”

Third, establishing a communist society was corrupted by the fact that it required a totalitarian regime to implement, oversee and often brutally enforce it existence, qualities it shared with the other twin spectre of 20th century government, Fascism. Workers might unite and revolt, but a ruthless tyrant was required to establish the government. Furthermore, enforcing its foundational requirement — a near-classless society — required forcefully “equalizing” the differences amongst people, the very ones which, in concert, benefited society: progress, invention, etc. I don’t need to describe the nature and destruction that such tyrannical force, justified with rabble-rousing rhetoric, wreaked on not only the countries themselves, but the world at large.

• How to get organization buy-in for the (supposedly) short-term pain of componentization? Had a strong long-term orientation culture from the start.
• Rather than directly jumping to microservices, started with a componentization approach that would leave the door open to microservices if desired. Decided it wasn't worth it after componentization. Architectural change rather than (service) topological change.
• Runtime analysis: built a tool that tracked cross-class calls that was run in test suite. Tracked violations of component boundaries. Numbers helped to gamify things and get people interested. However, canned tool because feedback was not actionable.

  • Followed up by Packwerk which is a much simpler static analysis tool. Only tracks static references. Less comprehensive and doesn't attempt to handle metaprogramming, but also less false positives. Same loading rules as Zeitwerk.
• Architecture: need to think about component interfaces (aggregate of all classes) instead of just class interfaces. Bad class interfaces muddle component interfaces.
• Two types of cohesion:

  • Functional cohesion: code that performs the same tasks live together
  • Data cohesion: code that operates on the same data lives together (very OOP, pushed by ORMs)
• Insights into Shopify team structure

  • Traditional teams
  • Opt-in "guilds" that are like meetups; don't try to carry out changes but strategize on grass roots approaches
  • Technical leadership committee -- rotational; participates in tech design reviews (basically cross team tech leads)
• "My experience tells me that a temporary incomplete state [of any migration] will at least last longer than you expect. So choose an approach based on which intermediate state is most useful for your situation."

I like having ideas, launching businesses around ideas, and bringing them to profitability (winning Level 1). And I'm pretty good at this, evidently. But I really don't want to be the guy whose job it is to win Level 2. I don’t like playing Level 2, it's way harder and more toilsome, and it militates against what I most want to be doing, which requires copious leisure. Leisure isn't just time not working. It's a distinct state.

On net, I probably spend more time engaged in free thinking and creating now than I did as a professor, but one has to grind much harder to be a winner in the business world. I don't even care about the business world, but once I start playing a game, I want to be a winner in that game. I don't need to be a top 1% winner, but I can't help but want to be at least a top 5% winner. If I'm going to do it, then why not try to win? But managing these things and keeping my effort reflective of my real ultimate goals has turned out to be extremely stressful. A lot of existential anxiety as well.

1. 1.

   Money. Barring anomalies like Google (where, honestly, the culture of "coasting" is overly exaggerated), my income would probably drop by over 50%.
2. 2.

   Flexibility. I talk to my peers at "easy" jobs, and they tend to give limited PTO, have more red tape, etc.
3. 3.

   Loss of control and influence. Simply put, if you are unfirable, so is everyone else. Without the specter of punishment for bad behavior, everyone has the opportunity to be selfish at the expense of everyone else, withholding cooperation for personal gain.

1. 1.

   Fulfillment. There is a culture war today between the 996ers and the "lying flatters" (which, for the record, is one of the funniest social movements I have ever seen). I am somewhere in between in that I actually do get a good deal of personal satisfaction from my professional success. I hear people parrot all the time that tying one's career to one's personal fulfillment is unhealthy, but what can I do, the thing that fulfills me just so happens to pay the big bucks, and I don't like being bored.
2. 2.

   Meeting my own potential. This is a tougher, more abstract version of fulfillment. I consider myself reasonably smart, with parents who worked extremely hard to give me a good education. At this point in my life, it feels like it would be a waste of my own potential to coast instead of trying to strive for achievement. Many people similarly parrot that one has no obligation to anyone to rise to the expectations of them at the expense of one's own comfort, but... I don't know. I disagree. I don't have a good way of putting it into words, but I disagree. Vehemently. Maybe it's the sense of duty so ingrained into Chinese culture.
3. 3.

   Competitiveness. This calls back to Justin Murphy's need to be a "top 5% winner". I'm an inherently competitive person, be it for work or for play, and when I get to work with an engineer that I consider to be better than me, I basically obsess over how I can get to (and exceed!) their level. I think about our relative merits and weaknesses, and think about the edges I can hone. Is it psychologically unhealthy? Maybe, but I can't stop! It's my natural impulse.

• ​Productivity in the age of hypergrowth - Lethain​

  • One of my biggest concerns at Persona is VC growth pressure throwing off the ratio of onboarding vs. experienced engineers, so this was a timely read.
  • "There are a non-zero number of companies which do internal documentation well, but I’m less sure if there are a non-zero number of companies with more than twenty engineers who do this well. If you know any, please let me know so I can pick their brains."
  • "The best system rewrite is the one that didn’t happen, and if you can avoid baking in arbitrary policy decisions which will change frequently over time, then you are much more likely to be able to keep using a system for the long term."
  • I've been doing a lot of reading on scaling (company-wise, not just architecturally). The term "blast radius" comes up. A LOT.
  • No other summary. Everything is timely. Just... read this again once in a while, future me.
• ​How to invest in technical infrastructure​

  • "When you have surplus engineering capacity, folks tend to have a long backlog of stuff they’d like to work on, and many teams immediately jump on those, but I think it’s useful to fight that instinct and to step back and do deliberate discovery." Rings true to me. Everyone I know where I work has "shadow backlogs", and LIFO feels natural, but it really may not be the most ideal. Be more thoughtful about prioritizing excess capacity.
  • "If you’re prioritizing without your users' voice in the room, your priorities are wrong."
• ​Migrations (or, avoiding the company killing full rewrite)
• ​Forty year career​

  • More about personal scaling than business scaling. Also has a great collection of bloggers and thinkers halfway in.

• During the advent of SQL, there generally wasn't that big of a need for scale. Consistent (due to everything being in one node) and available. Sharding was hard but was a comparatively rarer need compared to today (peak thoroughput was 10-100 transactions/sec; peak storage was a handful of terabytes). Developers disliked sharding as it was a leaky abstraction at times; "eBay’s middleware in 2002, for example, required their developers to implement all join operations [when partitioned] in application-level code" (Pavlo & Aslett, 2016). Additionally, sharding makes indexing hard as indexes might not be partitionable the same way as the data.
• In the "web scale" / NoSQL era, people found that they needed massive scalability, support for many concurrent users, and to be online at all times. High availability was chosen over consistency, and NoSQL DBs generally chose to rely on eventual consistency.

  • "Transactions don't scale;" two-phase commit (change + verify all nodes) performance viewed as unacceptable; replicas allowed to diverge; writes may not persist after merge conflicts; reads may not be latest; state at any given read may not have yet converged; given enough time after any inputs, all replicas will return the same results for a read).
  • Schemaless nature made sharding easy (see Mongo auto-sharding).
  • The relational data model was seen to often be unnecessary overhead, with alternatives like k-v, graphs, etc. being seen as better fits at times. However, due to the lack of transactions, developers switched from wasting time implementing joins at the application level to wasting time handling inconsistent data.
• In today's cloud-native / NewSQL era, many new entrants purport to offer strong consistency, enough availability, and strong partition tolerance, with the goal of ACID-guaranteed transactions + scalable performance of NoSQL. The rationale is that even with a perfectly available DB, you will never get "true" real world availability given things like network errors, so it's better to optimize for the other two. Lack of transactional guarantees was often the dealbreaker for NoSQL.

  • New architectural patterns, more efficient storage engines, better sync strategies for nodes (e.g. atomic clocks), better abstraction of sharding middleware

    • Moving from structured data model with appending rows to tables with IDs as primary keys + index (which is hard to distribute) to tables as K-V store -- each row has a non-ID column identified as a primary key (link). Keys are table/index/key/columnName and value is column value. (Imagine CSV index-based access via ID + column name.) (Embedding extra data in key, e.g. country code, allows easy partitioning by region.)
    • Partitioned indexes instead of replicated indexes
  • Improved overall technology; commoditization of compute and memory

    • Memory became cheaper vs. storage; feasible to keep entire databases in-memory. Optimizations like moving cold tuples to disk and replacing in-memory record with a pointer allow support for "larger-than-memory" loads.
• Aside 1: OLAP data warehouses meet some of the criteria sought by NewSQL. However they are read-only (barring data ingestion etc.), have much less performance demands (e.g. responses in the order of minutes can be acceptable), and are optimized for full table scans and large joins due to analytical requirements (which is overhead for most application needs).
• Aside 2: there were previous attempts to optimize existing RDBMS by swapping out the storage engine; replacements of row-based storage with column-based has found a niche with OLAP, but nowadays most NewSQL attempts aim at ground-up rewrites and brand new architectures.
• Besides operational benefits, easier partitioning + global cloud hosting solves for non-operational constraints like data residency laws

• ​Spanner: Google's Globally Distributed Database​

  • Page 5: Starts describing data model
  • Page 6: "We believe it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions."
  • Page 19: summary of prior art: layering transactions on replicated stores; Calvin for the idea of preassigning timestamps for transactions; temporal databasses allowing reads of past data; clock uncertainty bounds
  • Key insight on TrueTime: if the maximum error bounds are known, all we need to guarantee linearizability (complete global ordering) is to "wait out" the error time. Spanner's atomic clock based error time has an upper bound of 7ms (NTP is around 100ms~250ms which would be impractical).
• ​What’s Really New with NewSQL?​

  • In-depth historical overview of database trends, as well as a comparison of current NewSQL entrants
  • Page 48: covers shared architectural principles
  • Page 53: Table 1 shows a comparison of NewSQL systems
• ​NewSQL — The Next Evolution in Databases​

  • Historical overview of database trends; fairly light reading
• ​CockroachDB: Living Without Atomic Clocks​

  • Fun, accessible breakdown of how Spanner works (and how CockroachDB compensastes for not having "magic clocks")
• ​The Architecture of a Distributed SQL Database * CockroachDB​

  • Linked to section describing architecture / underlying data storage
• ​Jepsen analyses​
• ​Calvin: Fast Distributed Transactions for Partitioned Database Systems​

You also have to have some degree of taste. While “taste” can be hard to define precisely, in some sense, whatever the domain — whether it’s music or something else — if you spend the time and you put a lot of thought into appreciating something, teasing apart what makes it great, and building a thoughtful, opinionated perspective, that’s taste.

• ​Horizon charts - nice data visualization technique for line charts with multimodal peaks. Imagine a dataset where most values are between 1-100, but a subset spike to 1000-1100, and a further subset spike to ~10000. Compressing the Y-axis will destroy readability for the smaller ranges. Alternative to logarithmic scales for better glance value.
• ​Uber - Designing Edge Gateway, Uber’s API Lifecycle Management Platform - beyond being technically interesting, this article gives a sense of the time scales involved in building a massively scalable architecture. I think it also highlights that the viability of a design is a function of current business need.
• ​Cindy Sridharan - Testing in Production, the safe way - Cindy's articles are always a joy to read, jam-packed with information, and coupled with easily understandable examples.
• ​Amazon builder's library - lots of gems here, but Avoiding Insurmountable Queue Backlog and Caching challenges and strategies stand out by being entertaining and well-written on top of being simply informative.

1. 1.

   Take this capital by force, either by preventing people from leaving with their wealth, or by simply seizing it. (China is the most immediate example.)
2. 2.

   Preemptively kill all owners of capital (Southeast Asian Communists).
3. 3.

   Attempt appeasement (which has apparently never worked) (1972 Chile).

• One overlooked downside of SPACs is that how dilutive the merge ends up being is unclear up til the merge (because SPAC investors can choose whether or not to exchange their holdings). One consequence is that the claimed advantage of “price certainty” of SPACs vs. IPOs is overstated. Part 3 gets into this more (pp 18) and is the most interesting section IMO.
• Post-merger share prices tend to drop in price post-merger; people who exit their positions prior to the merger have better returns on average (resembles options in a way)
• On average, the larger the SPAC sponsor (e.g. if it’s a large private equity fund), the better the returns.
• SPACs being less regulated is a real advantage they have over IPOs as of now. NOTABLY, going public via SPAC doesn’t require you to file an S-1, so you’re a black box to retail investors and are essentially trading off of name brand alone (of both the company and the SPAC sponsor).
• SPAC sponsors take most of the returns, whereas SPAC shareholders end up bearing most of the risk/cost.
• TL;DR of the TL;DR: SPAC sponsors and SPAC IPO investors make out the best. SPAC holders who ride the wave and exit pre-merger make out ok. SPAC holders who hold post-merger are bagholders.

• Perfect really is the enemy of good. I'm a tinkerer, which leads me to stumble upon local maxima of "elegant code." But elegant code isn't the end goal -- product (and value) are.
• Spiking and dictatorially making decisions on areas of high uncertainty isn't actually that bad... as long as you remain open to change and are not afraid to throw code away.
• Running meetings and scoping features democratically is suboptimal. Parallelize work aggressively, grouping up as needed rather than as a default.
• Decisions should be made before meetings, not during meetings.
• Unit tests are overrated on the frontend. Integration tests are underrated.
• Writing suboptimal (or straight up incorrect) code is okay if the subject is easy to change. Being able to identify what's easy to change is the mark of a good engineer.
• Set hard date requirements instead of hard feature requirements. This will act as a forcing function to make you scope correctly. Even if you don't scope correctly, at least you have stuff done.
• When working with unfamiliar tech, just start writing code. Read documentation like novels (front-to-back), not like dictionaries (random access).

• Set dates first instead of features first. With featuers first, all dates end up being padded. Setting dates first forces you to really scope correctly and identify the MVP, and get to a state where you can start iterating. "Plan for 6 weeks and schedule for 3 weeks; plan to miss but aim to succeed."
• For the MVP, plan out acceptance tests, and adhere to them strictly. Use these as accountability tools for an objective measurement of progress. If an acceptance test is not passing by a deadline, really hone in on it.
• Learning how to correctly handle a big launch is hard. "This is why I don't recommend juniors join startups." At larger companies, you can fail without risking the existence of the company, and you can observe good practices. Because there are more large launches, you can evaluate them against each other for quality.

• Much of the US' continued presence in the Middle East is due to this policy.
• I've always wondered why the US maintained such close ties to the Philippines. This explains it, at least in part.
• Most interestingly, much of the basis of the Vietnam War was in the name of this policy.
• Nixon's 1972 China visit marked a priority shift from containing China to containing Russia.
• Much of this comes down to the US' hatred of communism. American interventionism itself can largely be explained by anti-communism. A secondary rationale was the intent to not repeat the mistake of appeasement towards Nazi Germany pre-WWII.
• The X Article gives some background into the US' ingrown anti-communism.
• One of Obama's big geopolitical moves in 2011 was a pivot of military resources out of the Middle East and into the APAC region.
• On the topic of Obama, the drone strike program was viewed as a black mark on his legacy. However, it's now known that the program was masterminded by the Bush administration, and during transition Bush pushed strongly for Obama to maintain this policy position. Similarly, Trump's trade war with China is seen as a black mark on his (fairly laughable) legacy; I wouldn't be surprised if this general policy position was carried over from the Obama administration.

• ​Linked Twitter thread​
• ​Podcast in question​