Weekend Reading #102
Weekend Reading: A weekly roundup of interesting Software Architecture and Programming articles from tech companies. Find fresh ideas and insights every weekend.
This week: bool.dev explores the transition from engineer to engineering manager; Meta separates ML feature releases from shared execution; Uber builds a common advertising platform with independent production fleets; and LinkedIn explains why its deployment model led to a custom GitOps engine.
6 Tips for the New Engineering Managers
👉 For new engineering managers and tech leads taking responsibility for a team
The habits that make someone a strong engineer can become bottlenecks after a move into management. This article connects six common challenges to concrete actions: let domain experts speak first, delegate decision authority explicitly, seek regular mentoring, address unsustainable workloads, record agreements, and treat the individual-contributor track as a valid career choice.
The most useful distinction is between assigning work and transferring ownership. An engineer cannot own an outcome if every meaningful decision still waits for the manager. Explicit delegation levels make that boundary discussable, while written decisions preserve accountability. Start with one recurring decision that currently needs your approval, agree who can make it, and review the outcome afterward. The initial slowdown is part of building capability across the team.
F3 Lightning: How Meta Accelerates Ads ML Features to Production at Scale
👉 For ML infrastructure engineers and platform teams reducing release coupling
Meta’s original F3 combined feature computations into one efficient graph, but also shipped that graph as one release. A broken feature could block unrelated changes. F3 Lightning compiles, validates, deploys, and rolls back each feature independently, then shares computation at runtime. Meta reports that comparable extraction features reach production roughly 3.6 times faster without increasing infrastructure compute costs.
The revealing detail is that removing duplicate computation was insufficient: scattered intermediate values still increased CPU use. A shared buffer and direct array indexing closed the gap. The broader architectural lesson is to examine release boundaries separately from execution boundaries. Independent delivery can coexist with shared execution, provided computation identity, dependency failures, and memory ownership are explicit.
Designing a Generalized Ads Marketplace Platform
👉 For software architects building shared platforms across multiple products
Uber separates its advertising platform into supply adapters, marketplace orchestration, and demand providers. A normalized AdSpec describes auction requirements, while extensions carry product-specific context. Providers can fail independently without aborting the entire request. Separate production fleets retain the same codebase while allowing independent deployments and rollbacks.
The useful lesson is that logical modularity and operational independence require different mechanisms. Provider boundaries contain individual request failures, but a shared deployment can still force unrelated teams to roll back together. Uber addresses both levels. For a smaller platform, first identify which products genuinely need separate release schedules or failure containment. Fleet isolation adds configuration and operational work, so it should follow concrete ownership and reliability requirements.
How we scale deployments with a custom GitOps engine
👉 For platform engineers operating Kubernetes deployment systems
LinkedIn replaced Argo CD for application deployments with an engine running inside isolated deployment pods. It compares desired, previously deployed, and live state; reconciles externally managed fields; and monitors each deployment until convergence or failure. In its year-over-year comparison, median time to conclude failed deployments fell from 16.1 to 2.45 minutes.
The decision depends on LinkedIn’s existing architecture: custom operators already provide ongoing reconciliation, and a central orchestrator manages deployments. Reproducing the engine elsewhere would also require covering those responsibilities. The broadly useful takeaway is to tie status to the exact deployment intent and surface actionable failures quickly. LinkedIn still uses Argo CD for cluster add-ons, and successful-deployment median duration remained comparable.