Hi I'm Juan! I'm a software developer from Argentina 🇦🇷living in the Bay Area.
On this blog I share the things I learn on software development and other related topics.
As a member of the Platform team, one of my responsibilities is to plan and execute large-scale migrations. These pose a unique challenge: how to get people to complete some tasks without any authority over them.
Maybe it’s because I’m an immigrant desperately trying to fit in. Maybe it’s one more way of keeping the imposter syndrome at bay. Whatever the reason, I’ve always been low-key obsessed with software development lingo. I’d go through meetings dropping principles and laws every chance I got. I’d lurk Slack channels waiting for a chance to pounce on a conversation to say “That’d make it worse based on Brooke’s Law” or “You’re falling for confirmation bias!”. Because I thought that gave me street cred. Same way I’d cover my laptop with stickers to showcase all the frameworks I knew and the conferences I’ve been to (but only if it was a modern framework and a “cool” conference). Just last week, I wrote a post teaching an imaginary audience about Conway’s Law and posted it on the social network for professional narcissists.
When I first joined the Netflix Platform team circa 2020, the Observability offering was composed of a series of tools serving different purposes. There was Atlas for metrics, Edgar for distributed tracing, Radar for Logs and Alerts, Lumen for dashboards, Telltale for app health, etc. It was a portfolio of about 20 different apps. Big and small, ranging from business-specific tools to analyze playback sessions to low-level tools for CPU profiling.
Pete Hodgson explored the different ways in which a Platform team works with other teams to get shit done in this article. I thought it was interesting to see how collaboration changes based on the type of work, so I put together this visual summary to compare and contrast each type of interaction.
Extension functions are great! But if you define them all over the place, it can get confusing pretty quickly. So here’s a cool idiom to limit extension function usage to a specific context.
Distributed tracing can be ridiculously expensive if you try to trace a hundred percent of requests. A common technique to reduce costs is to sample only a small portion of the traffic. But naive sampling techniques like uniform sampling will inevitably capture more common-case executions and might miss the more interesting edge cases. Instead, Sifter’s approach is to bias sampling decisions towards outliers and anomalous traces. This way, anomalous traces have a higher chance of being sampled, and the more uninteresting traces are discarded.
Lots of businesses run on Google Docs. It’s how we write memos, define strategies, discuss proposals, document decisions, write tutorials, and plenty of other things.
Google Docs is a fantastic piece of technology. I almost can’t imagine how we worked before it (productStrategy-Jun-2004-version13.docx anyone?). And yet, I sometimes feel like it could be so much more! Like we’ll look back in 10 years and think: “My god! I can’t believe we were working that way!”. Improving Docs has the potential of completely overhauling the way information flows through an organization. Here are some ideas on how Google could improve it.
Common knowledge says that you don’t deploy on Friday if you want to have a peaceful weekend. Yet, some people will tell you that if you’re not comfortable deploying every day of the week, you’re doing it wrong. They’ll say that deploying shouldn’t be scary and that you probably don’t have enough tests. So, which one is it?