- Pointer
- Posts
- Issue #556
Issue #556
Essential Reading For Engineering Leaders
Tuesday 8th October’s issue is presented by Speakeasy
Production API integrations are time-consuming for your users to get right.
Great SDKs help but have traditionally been hard to build & maintain. Speakeasy’s platform now makes crafting type-safe, idiomatic SDKs for enterprise APIs easy.
Check how Speakeasy compares to open-source generators and choose the best option for your API.
— Subbu Allamaraju
tl;dr: “The metaphor helps debug the root causes behind managers struggling with busy calendars, not investing in themselves, not having detached vacations, or, more importantly, not having time to be strategic. In this article, let me introduce that metaphor visually and point out some techniques to address the root causes.”
Leadership Management
— Nitin Dhar
tl;dr: Nitin provides example answers to each of the following: (1) What is the KTLO cost for the team? (2) What is the impact of project X? (3) When will project X be live to customers? (4) What's the overall impact of your team? (5) How much tech debt do you have? (6) What's the team's mean time to recovery (MTTR) from incidents? (7) How much churn (throwaway work) have you seen in recent sprints?
Leadership Management
tl;dr: API design is important, yet it is only useful if it's well-documented and consistently represented across every API surface area (docs, SDKs, etc.). OpenAPI gives you greater visibility into your API, enabling you to unify all aspects of errors, responses, and parameters, ensuring consistency. This open-source documentation project will help you understand the OpenAPI Specification.
Promoted by Speakeasy
API
— Kent Beck
tl;dr: “If you want more changes to get through, you need to expand the far end of the hose, to increase deployment capacity. You can do this the hard way, by reducing the deployment cycle and dealing with the ensuing chaos, or the harder way, by increasing the number of changes per deployment (better tests, better monitoring, better isolation between elements, better social relationships on the team). But don’t try to reduce overhead. That’ll just lead inevitably to a series of meetings on how to reduce meetings. At least that will keep you from trying to ship too much code, though.”
Leadership Management
Editor’s Note
If anyone you are an illustrator, or you know someone talented, please reply to this email as we’re looking for someone to work on a small project.
— Will Larson
tl;dr: “Models are imperfect representations of reality, but this one gives us a clear sense of what matters the most: if we want to increase our velocity, we have to reduce the rate that we discover errors in production. That might be reducing the error rate as implied in this model, or it might be ideas that exist outside of this model. For example, the model doesn’t represent this well, but perhaps we’d be better off iterating more on fewer things to avoid this scenario. If we make multiple changes to one area, it still just represents one implemented feature, not many implement features, and the overall error rate wouldn’t increase.”
AI Productivity Management
tl;dr: This article explores how Pinecone used Fern's SDK generator to create its C# SDK with both gRPC and REST support - the first of its kind! Learn more about the benefits of using Fern to automate SDK creation and maintenance across multiple API languages.
Promoted by Fern
SDK API
— Lorin Hochstein
tl;dr: (1) Nobody fully understands how the system works. (2) The gaps in our understanding of how the system works contributes to incidents. (3) The way that work is done profoundly affects incidents, both positively and negatively, but that work is mostly invisible. (4) Incident reviews are an opportunity for many people to gain insight into how the system works. (5) The best way to get a better understanding of how the system behaves is to look at how the system actually behaved. And more.
Incidents
— Christian Hollinger
tl;dr: “How we built it, what we learned, as well as some selective deep dives I found interesting enough to be worth sharing in more detail, since they’ll bridge the gap between what people usually understand by the term “data engineering” and how we run data here at ngrok. Some of this might even be useful for your own data platform endeavors, whether your team is big or small.”
Platform Data
tl;dr: “How we made efficiency improvements to Uber’s Experimentation platform to reduce the latencies of experiment evaluations by a factor of 100x (milliseconds to microseconds). We accomplished this by going from a remote evaluation architecture (client to server RPC requests) to a local evaluation architecture (client-side computation). Some of the terminology in this blog post (e.g., parameters, experiments, etc.) is referenced from our previous blog post on Uber Experimentation. To learn more, check out Supercharging A/B Testing at Uber.”
Architecture
Most Popular From Last Issue
Git Absorb - Stephen Jung
Notable Links
Agents: Build real-time multimodal AI applications.
Core: OS home automation.
Kestra: Event-driven orchestration platform.
One: React framework that makes cross-platform simple.
StarbaseDB: HTTP SQLite scale-to-zero DB.
How did you like this issue of Pointer?1 = Didn't enjoy it all // 5 = Really enjoyed it |