tl;dr:This week I had a conversation with one of our engineers about “shitty code” which lead me to sharing with him one of my more unusual inspirations: Flamework, a pseudo framework created at Flickr. Armin discusses the framework, which he describes as “messy but effective.”
tl;dr:“But there is a simpler path. You write code yourself. Sure, it's more work up front, but once it's written, it's done. No new crates, no waiting for upsteam authors to fix that edge case. If it's broken for you, you fix it yourself. Code that works doesn't necessarily need the maintenance treadmill. Your code has a corner case? Who cares. This is that vibe shift we need in the Rust world: celebrating fewer dependencies rather than more.”
tl;dr:“Most software that exists today does not forget. Creating software that remembers is easy, but designing software that deliberately “forgets” is a bit more complex. By “forgetting,” I don't mean losing data because it wasn’t saved or losing it randomly due to bugs. I'm referring to making a deliberate design decision to discard data at a later time. This ability to forget can be an incredibly benefitial property for many applications. Most importantly software that forgets enables different user experiences.”
tl;dr:“What if platforms like AWS or GitHub started splitting the check? By adding a line-item to the invoices of their customers to support Open Source finding. It would turn giving to Open Source into more of a tax like thing. That might leverage the general willingness to just pile up on things to do good things. If we all pay 3% on top of our Cloud or SaaS bills to give to Open Source this would quickly add up.”
tl;dr:The author describes how they dealt with tech debt in their Rust library caused by a dependency. When the dependency was flagged as insecure by RUSTSEC, users demanded action. Alternatives were unappealing, so the author merged the dependency's code into their own library, effectively "collateralizing" the tech debt and upgrading it from "junk" to "AAA" status.
tl;dr:Armin observes two forms of pessimism - a “pragmatic form” and what he’s coined as “destructive pessimism,” which he believes has become more common inside and outside of engineering. Pragmatic pessimism can be useful - you assume that things are more difficult than they actually are and are able to highlight pitfalls along the way. Destructive pessimism wants, or expects, things to fail. While both seem similar on the surface, the latter can be harmful.
tl;dr:Podcast episode where Armin talks about the origins of Flask, the components that make up the framework, documenting a framework or API, and how he would do it all differently now.
tl;dr:Async has recently become popular. It's analyzed from the perspective of Flow Control and Back Pressure, concepts that prevent systems from overloading that are commonly overlooked.
tl;dr:Armin wants a post-mortem on how the transition to Python 3 has been handled. There's a lack of transparency as to why the transition is needed. He feels like he's being "sold" and forced into migrating when, in fact, there are other reasons this migration is needed.