Loading…
Browse by type
Explainer reads
Explainer posts on Yomu, summarised newest first.
- 1,379 posts
- 20 companies
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Explainer posts
Making big bets in business
The post argues that startups should pursue asymmetric outcomes: bets with potentially large upside and limited, manageable downside, rather than optimizing for average advice or minimizing every risk. Drawing on the founders’ experience building Paribus and Ramp, it applies this principle to choosing a problem space, hiring, vendors, product development, and fundraising. An outsized seed round enabled Ramp to pursue financial services despite high barriers to entry, while early hiring favored exceptional, fast-growing people over candidates who matched every competency checklist. It also recommends testing scrappy vendors, listening to customer problems rather than proposed solutions, and selecting reputable investors with clean terms. Ramp’s counterexample is credit risk: because revenue is about 1% of lending, a mistake can cost roughly 100 times its reward, so threatening risks should be isolated from bolder bets.
Journey Through a Dev Degree Intern’s First Placement
During her first 12-month Dev Degree placement, the author worked as a back-end developer on Shopify’s Docs & API Libraries team, which builds libraries, tools, and documentation for developers. She describes an initially steep learning curve through work on Shopify CLI, including a change allowing Rails flags such as --db=DB during project scaffolding, and a Shopify Admin API Library for Node written in TypeScript. To handle uncertainty, she kept an Achievement Log, learned by adapting existing code and tests, paired with colleagues, asked for help, and reviewed draft pull requests with teammates. The placement challenged stereotypes about “real” developers and showed that imposter syndrome can coexist with genuinely needing more knowledge. She concludes that learning is collaborative, representation can strengthen inclusion, and becoming comfortable with discomfort is part of development.
Reusing Code with React Native Packages at Shopify
Shopify’s React Native teams needed to reuse shared functionality across Shop, Inbox, Point of Sale, Shopify Mobile, and Local Delivery without requiring each team to build and maintain separate package infrastructure. The React Native Foundations team chose a monorepo containing npm packages, a fixture app, shared root configuration, generated CI, and an internal documentation site, with code generation for package bootstrapping. Packages use TypeScript project references, Yarn Workspaces, Lerna publishing, and custom Babel, Metro, and Podfile configuration to support cross-package references, hot reload, and local native dependencies. Dependency graphs and file-change triggers limit CI work to affected packages and dependents, while independent versioning and release scripts manage publication; since June 2020, 17 packages have been developed, including 10 contributed by product teams, although release automation and coordination across multiple monorepos remain future improvements.
Shard Balancing: Moving Shops Confidently with Zero-Downtime at Terabyte-scale
Shopify’s MySQL shards can become unevenly utilized as merchants grow after being assigned to arbitrary shards, increasing over-utilization risk while leaving other capacity underused. The post describes a strategy for selecting shop placements using historical utilization and traffic data, simulations, and potentially other metrics such as shop size, GMV, and move time. It then explains online shop migration with Ghostferry, which batch-copies records and tails MySQL’s binary log before a brief cutover updates the routing table and directs new writes to the target pod. Verification checks data completeness, integrity, and stale traffic before old data is pruned; the migration system’s central algorithm is also represented in a TLA+ formal specification. The stated outcome is a more balanced infrastructure that can isolate high-traffic merchants across pods with virtually zero consumer-facing downtime.
How We Got to LiveView
Chris McCord recounts how Phoenix and LiveView emerged from attempts to make real-time features as simple as Rails CRUD development. He first built sync.rb, which used WebSockets to re-render server-side templates and push HTML updates without requiring programmers to write JavaScript, but Ruby’s concurrency model and EventMachine proved unreliable for the task. He then turned to Elixir and the Erlang VM, whose lightweight message-passing processes and fault tolerance supported Phoenix Channels and a reported load test of 2 million concurrent WebSocket connections on one server. LiveView unifies client and server state in a stateful process that synchronizes only necessary HTML changes. The account also describes binary uploads, WebSocket-based navigation via live_redirect and live_patch, and HEEx, an HTML-aware Elixir template syntax with compile-time validation.
Engineering Principles at Ramp
Ramp documents seven engineering principles intended to codify how its teams build systems, make decisions, and collaborate as the company grows. The principles call for choosing technology according to each system’s context, moving aggressively on reversible decisions while treating durable interfaces cautiously, and aligning system models with customer concepts. They also favor opinionated product experiences, accepting duplication over a harmful abstraction while continuing to seek abstractions that reflect meaningful shared behavior. Rather than implementing requests literally, engineers investigate underlying needs, such as notifying a CFO instead of making approval a bottleneck, and break projects into small, independently prioritized chunks. These chunks can be owned by small teams called “pods,” while the principles remain adaptable rather than ironclad rules.
Using Rich Image and Text Data to Categorize Products at Scale
Shopify revisited product categorization as its platform expanded to millions of merchants selling billions of products across diverse industries. The model uses product titles, descriptions, types, vendors, collections, tags, and images, converting them into embeddings with Multilingual BERT and MobileNet-V2 before hierarchical classification across the seven-level Google Product Taxonomy. Each taxonomy level is treated as a separate multi-class task, with parent predictions fed into child predictions and weighted losses combined during training; confidence thresholds filter predictions at each level. The upgraded system increased leaf precision by 8% while almost doubling coverage, although thresholds require balancing accuracy, coverage, merchant experience, and performance in sensitive categories, and future work includes addressing data imbalance and adding merchant-level features.
My summer at Ramp
My summer at Ramp recounts a three-month internship at the financial automation startup, following an introduction to its mission, growth, and product. During the placement, the author standardized physical-card shipping data, improved accounting workflows, handled profile-picture and UX work, and resolved production issues while improving endpoint and application performance. The main project, Filtering and Renaming GL, let Ramp administrators control accounting-option visibility by cardholder department and rename cryptic options within Ramp. The internship also provided observations about fintech opportunity, Ramp's rapid growth, transparency, ownership-driven culture, and the speed-quality trade-off described as product velocity. The author planned to continue at Ramp part-time while entering the third year of college.
5 Steps for Building Machine Learning Models for Business
The article presents a five-step workflow for deciding when and how to build machine learning products in a business setting. It recommends delaying machine learning for new products, establishing data-collection foundations, and testing simple heuristics as baselines before investing in a model. For an initial model, teams should favor simple algorithms, limited feature sets, and off-the-shelf solutions where appropriate, then measure business-aligned impact before optimizing. The workflow also calls for planned model iteration and explicit comparison with existing versions, while accounting for prediction stability when changes could affect user trust. The authors say they used these practices at Shopify to help build and scale machine learning products and to productionize models intended to drive impact.
API Tokens: A Tedious Survey
The post surveys API token schemes in the context of designing fine-grained permissions for Fly.io’s control-plane API, which currently provides all-or-nothing root credentials. It compares simple random tokens, platform tokens, OAuth 2.0, and other formats and protocols against revocation, database access, and vulnerability concerns, while distinguishing end-user API security from inter-service authentication and federated identity. The discussion explains how stateless signed tokens trade database lookups for cache-consistency and revocation problems, then presents Macaroons as a scheme the team plans to adopt, while noting that their expressiveness may be excessive for typical CRUD applications. Biscuits extend that model with public-key signatures and Protocol Buffers-encoded Datalog programs, offering unusually explicit authorization rules but demanding a potentially wholesale commitment to token-based policy. The conclusion favors simple random tokens for many CRUD applications, chooses Macaroons for the planned system, and advises against JWT.
Diggin’ and Fetchin’ with TruffleRuby
The investigation starts with production Ruby code that chains Hash#fetch calls and uses an empty-hash default to return an IdentityObject for missing nested data. It compares that workaround with Hash#dig, which is cleaner but does not provide fetch's same control over missing keys, defaults, and explicit nil values. To prototype a combined Hash#dig_fetch method, the author modifies TruffleRuby, using Primitive's hash_get_or_undefined and undefined? to distinguish absent keys from keys containing nil, then replaces recursive traversal with an iterative implementation in shared Diggable logic. For a hash with nine nested keys, iterative changes lift dig from about 2.5M to 16M iterations per second and lift dig_fetch from about 2.5M to 15.5M. The dig_fetch prototype enables the original refactor, but it is not ready for general Ruby adoption because Array and Struct interoperability and corresponding MRI work remain.
Modelling Developer Infrastructure Teams
Developer Infrastructure at Shopify spans local and cloud development environments, CI systems, deploys, and technology-specific foundations for web and mobile applications. The post models these teams against a three-phase develop–validate–deploy workflow, distinguishing horizontally integrated teams that own one phase from vertically integrated teams whose systems span phases for a particular technology. It uses this model to identify dependencies, gaps, differing scopes, collaboration patterns, and three work avenues—concentration, expansion, and interfacing—with the mission of improving and scaling the cycle. The analysis informed organizational changes, including a Client Foundations team, closer collaboration, and plans for workflow-wide user research focused on the developer journey from writing a patch to production.
Bridging the Gap Between Developers and End Users
Shopify describes how distance between developers and end users can weaken product context and empathy as companies grow. The company created Bridge the Gap in 2014, connecting employees with merchants through Support teams. The program uses workshops, an internal podcast built from support-call clips and discussions, and voluntary one-hour shadowing sessions in which participants observe Support Advisors helping merchants via chat, phone, or email. Direct exposure is presented as a way to understand unexpected product use, identify customer workarounds that may inform fixes or new products, broaden domain knowledge, and develop listening, communication, patience, empathy, and expectation-setting skills. The broader goal is to make merchants accessible to Shopify’s workforce as people rather than abstract accounts or personas.
Connecting with Mob Programming
A six-person team drawn from three teams had six weeks to complete an ambitious Shipping project, while several members were new to the domain or company and had not worked together. Pairing was uncommon, and pull requests received little substantive feedback, creating uncertainty about whether the team was growing, connecting, and learning. After Sheldon Nunes introduced mob programming, the team used a shared screen and ten-minute driver rotations, with each driver pushing changes before the next person pulled them. This kept everyone engaged, accelerated reversible decisions, limited context dumps, and made most code review back-and-forth unnecessary. Across nearly daily sessions for three months, the team reported stronger relationships, easier feedback, restored remote learning, and better support for newcomers, while identifying drawing, public discoverable calls, simple environments, cross-disciplinary participation, and breaks as important practices; tests and documentation were considered poor fits for mobbing.
Spot: a video sharing app built with Flutter
Supabase compiles a broad index of case studies documenting how organizations deploy its platform for infrastructure, authentication, and database workloads across diverse industries. Multiple companies report significant operational efficiencies, including Quilia reducing development time by seventy-five percent through Data API and row-level security capabilities. Infrastructure migrations are highlighted prominently, with Shotgun achieving an eighty-three percent reduction in data infrastructure costs and Good Tape cutting expenses by sixty percent. Several teams also adopt the platform specifically for artificial intelligence workflows, such as Quivr deploying thousands of vector databases and Firecrawl transitioning from Pinecone to Supabase Vector. Other organizations, including Mobbin and Replenysh, use the platform to migrate hundreds of thousands of user accounts and implement one-time password systems within twenty-four hours.
A Guide to Running an Engineering Program
Shopify describes a playbook for running large engineering programs as platform complexity grows across products, tooling, and architecture. The framework begins with a Program Plan covering the problem statement, objectives, guiding principles, definition of done, risks, mitigation, staffing, scope, and a path to completion. Execution uses six-week cycles that revisit unfinished goals, regressions, emerging risks, and the planned route to completion; the described program spans 200 people, nine sub-organizations, and 92 projects. Supporting rituals include weekly updates, status checks, risk and escalation triage, cycle reviews, retrospectives, RFCs, and performance testing with Lua scripts orchestrated by Genghis. The post concludes that engineering program management must adapt to each organization and that a combination of scheduled and ad hoc rituals helped Shopify pursue its goals.
Processing ETL tasks with Ratchet
Grab's Lending team relies on multiple microservices to finance various user segments, requiring automated pipelines for operational tasks like loan rescheduling and merchant whitelisting. To execute these workflows, the team uses Ratchet, a Go library that organizes data pipelines into concurrent stages connected by Go channels and JSON payloads. In the Azkaban service, each ETL task is structured as a Job Processor that configures custom Data Processors for extraction, transformation, and loading. For merchant whitelisting, a custom processor pulls uploaded CSV files from Amazon S3, validates the rows to prevent manual errors, calls microservice APIs, and passes the output to an empty load stage. This pipeline architecture allows the team to isolate failures quickly, eliminate manual data validation, and automate routine operational tasks.
Perspectives on React Native from Three Shopify Developers
Three Shopify developers—web developer AJ Robidas, Android developer Michelle Fernandez, and iOS developer Ash Furrow—describe how React Native changes mobile development for people from different backgrounds. They say its React-based model lets web developers build for iOS and Android, helps native developers create interfaces faster and reach a wider audience, and supports collaboration across web, Android, and iOS teams. The developers discuss surprises including React Native’s small set of building blocks, fast UI feedback, native bridge modules, existing SDK integration, and apps that can be difficult to distinguish from Swift or Objective-C software. They also identify challenges such as mobile-specific performance concerns across the RN Bridge, the Metro and Node ecosystem, and the large dependency stack. At Shopify, Visual Studio Code, command-line tooling, internal foundations, workshops, and cross-disciplinary teams support adoption.
Shopify-Made Patterns in Our Rails Apps
Shopify describes patterns and infrastructure adaptations used to keep its large Rails monolith maintainable as its organization and platform scale. Its dev command-line tool standardizes project setup, dependencies, services, environment variables, integrations, and command aliases across hundreds of active projects. Shopify Core uses pods to partition shops across independent databases and extends the shard concept across provisioning, deployment, load balancers, caching, and servers, while splitting code into domains without separate databases. The post also details safeguards including short-term Active Record migrations consolidated periodically into structure.sql, automated tests, a pod-aware maintenance task system, and a translation platform that commits translated strings through Git. Finally, Monorail imposes versioned JSON event schemas between Kafka producers and consumers and supports review and automated scrubbing of PII fields.
High Availability by Offloading Work Into the Background
Unpredictable traffic spikes, slow third-party payment requests, and resource-intensive image processing can overwhelm an application, making it slow or unavailable; the text presents background jobs as a way to preserve meaningful user interactions. High availability is defined not merely as server uptime, but as users being able to interact with the application when needed. The application server places a task message in a queue and continues serving requests, while workers process jobs asynchronously, with support for retries, parallelization, prioritization, and event- or time-based scheduling. Offloading improves response times and buffers spikes, but changes immediate guarantees: an upload may be accepted before processing succeeds, and errors may be handled later. For distributed systems, data-based messaging such as RabbitMQ can connect different services, while Kafka's append-only, replayable event log supports shared consumption and event sourcing.
Top topics
- Architecture834
- Performance816
- LLMs669
- Machine Learning622
- Open Source567
- AI Agents560
- AI480
- Developer Experience448
Weekly digest
The best engineering reads, once a week.