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 | | 1 | 2 | 3 | 4 | 5 |
|
|
