Loading…
Browse by type
Explainer reads
Explainer posts on Yomu, summarised newest first.
- 1,363 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
Lessons from my internship at Ramp
The author reflects on a three-month software engineering internship at Ramp from March to June, describing lessons about execution, company choice, and location. Ramp’s charge card appeared to be a commodity, but the author credits its bias for shipping quickly, technical and product strength, differentiated technology, and favorable capital secured through finance expertise with turning it into a distinctive product. Compared with more formal, lower-stakes internships, Ramp offered flexibility, mentorship, and exposure to a fast-growing organization, although its pace and limited documentation could be challenging. The experience also shaped the author’s view that working on large problems at such a company can magnify impact, while New York provided experiences and a tech community distinct from San Francisco’s.
The Age of Machine Learning As Code Has Arrived
Recent findings from the 2021 State of AI Report and Kaggle State of Machine Learning and Data Science Survey indicate that machine learning is expanding into critical infrastructure while Transformers become general-purpose architectures across text, vision, and audio. In response, organizations face questions about scaling infrastructure, team composition, and engineering maturity. Rather than treating machine learning as isolated sandbox experiments or hiring solely data scientists, teams benefit from adopting established software engineering and DevOps principles like versioning, testing, automation, and continuous deployment. Furthermore, the rise of pre-trained Transformer architectures enables practitioners to fine-tune existing off-the-shelf models rather than training from scratch, reducing compute costs and training duration. Tools from platforms such as Hugging Face streamline model deployment, latency optimization, and infrastructure abstraction.
32 Bit Real Estate
Fly.io’s globally distributed network needs routable IPv4 addresses because it assigns distinct public addresses to applications, including non-HTTP services such as UDP DNS servers and TCP game servers. The post explains how address control depends on Regional Internet Registry transfers, a BGP4 ASN, upstream peering, and advertising the same address from multiple locations for Anycast routing. IPv6 and TLS SNI can reduce address demand, but IPv6 connectivity remains unreliable for many users and SNI does not cover non-TLS applications; keeping separate provisioning paths is also considered undesirable. IPv4 blocks are therefore bundled with apps, while outright acquisition is preferred to leasing because addresses can remain assigned indefinitely, despite future IPv6 obsolescence and the risk that their value could eventually fall to zero.
YJIT: Building a New JIT Compiler for CRuby
YJIT is a new just-in-time compiler being built inside CRuby to improve Ruby performance on modern hardware, where single-core speed gains are limited and energy efficiency matters. Unlike MJIT’s weaker results on large real-world applications, YJIT uses a data-driven focus on performance hotspots in Rails and Shopify Core and is based on Basic Block Versioning (BBV). After about one year, it reports speedups over the CRuby interpreter of 20% on railsbench, 39% on liquid template rendering, and 37% on activerecord, with near-peak performance after one benchmark iteration. YJIT passes CRuby’s roughly 30,000-test suite, Shopify Core and GitHub backend CI, while running on a small percentage of Shopify production servers; its team plans further CRuby changes and broader JIT coverage before and after its intended Ruby 3.1 integration.
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.
Top topics
- Architecture832
- Performance814
- LLMs658
- Machine Learning620
- Open Source563
- AI Agents548
- AI465
- Developer Experience448
Weekly digest
The best engineering reads, once a week.