Interesting Reads, #1

This article is just what the title says — practical. I’ve found that working on improving performance at a large scale can be as frustrating as it is rewarding at times. Easy enough to see where the problems are, tough to diagnose the root cause of the problem, and even trickier to come up with a fix. I enjoyed the visuals and concrete examples in this article, it’s a great place to start with web/JavaScript performance.

I saw the Prime Video team catching flack for this article on the Twitter after it came out. “LOL, Amazon says not to use Lambdas!” “The only reason they used Lambda was because upper management forced them to!” However, I feel like this was the key quote in the article:

“We designed our initial solution as a distributed system using serverless components (for example, AWS Step Functions or AWS Lambda), which was a good choice for building the service quickly. In theory, this would allow us to scale each service component independently. However, the way we used some components caused us to hit a hard scaling limit at around 5% of the expected load. Also, the overall cost of all the building blocks was too high to accept the solution at a large scale.”

Rethinking your architecture is good. Changing your architecture based on how the product actually scales and is actually used is good. I think this article on Monoliths by Werner Vogels, Amazon CTO was an informal companion to this technical blog post.

I’ve been a passive follower of all the AI stuff happening, consuming updates mainly via Twitter and internal Microsoft stuff. This article highlighted the pace at which AI-related tech is advancing, but I thought the most interesting part was the meta-commentary about the differences between building software in an open-source community, at a startup, or at Google scale. The thoughts about working with the open source communities instead of in competition with them is something that I think can be done better outside of AI as well, especially given that they’ll always have the big step up: money.

I admittedly haven’t designed a command-line interface (CLI) before. The thought that went into this design impressed me and made me realize how restrictive the design space is for CLIs. This one’s worth reading alone as a treatise on respecting the craft and a lens through which you can look at the importance of designing for clarity and the microinteractions that we develop on a daily basis.

I straight up hated statistics when I took it in high school. I’m not sure why, but I just couldn’t find anything exciting about it. Fast forward a decade (if we’re being generous) and now I use it almost every day in both work and hobby. And I like it. This article has some really nice visuals on regression techniques and is a well-written primer on one of the most common tools in the statistical analysis toolbox.

Yeah, I don’t quote remember how I came across this again either. If you’re not into basketball and/or brief basketball history, you can stop around page seven. Before that spot; however, is a joyful read on markets, evaluating their inefficiencies, and how to think about making predictions and evaluating them as their times come to pass. As I said in the intro, I’ve been getting more into basketball analytics, and the Sam Hinkie “Trust the Process” era is always fun to read about. It’s oddly philosophical for a resignation letter, but truly fun and I know I’ll read it again soon.

I’ve been slowly making my way through this one. It’s an interesting book about the practical uses of mathematics that drive our decision making, extraordinary (seeming) events, and other uses of math along those lines. My favorite take away thus far has been thinking about more things in term of utility or expected value and how that might change decisions I make. It’s a bit long, but if you enjoy math you’ll enjoy this book and its fun examples and anecdotes.