Loading…
Browse by type
Explainer reads
Explainer posts on Yomu, summarised newest first.
- 1,382 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
How We Enable Our Interns to Make an Impact
Shopify describes an internship model in which interns work on projects affecting merchants, partners, and developers, including merchant pain points such as selling across channels. The program combines autonomy comparable to that of full-time employees with mentorship, regular pair programming, unfamiliar challenges, and cross-team collaboration. Examples include launching the Amazon Channel, changing an Android app design pattern across multiple codebases while limiting effects on third-party developers, backfilling affiliate data with Elasticsearch and Ruby on Rails, and generating Java and Swift models from a strongly typed GraphQL schema. Interns are encouraged to investigate open-ended problems, consult documentation and stakeholders, and develop informed recommendations with mentor support. Returning interns can change teams or roles, while tools such as Slack enable direct communication across the organization; the stated result is practical experience, deeper technical knowledge, and potential full-time opportunities.
Tell Your Stories: The Benefits of Strategic Engineering Communications
Shopify created engineering communications in early 2016 as rapid growth and expansion from four to five offices made informal knowledge sharing insufficient. The program serves internal and external audiences through weekly technical talks, an internal newsletter, engineering-blog posts, conference presentations, and an editorial calendar, with Shopifolk developers treated as a primary audience. Communications staff hunt for stories by building relationships with project leads, then coach speakers and work alongside developers while preserving their voices; coaching covers narrative, breath control, body language, and calls to action. The reported effects include less risk of duplicated work or mistakes, cross-pollination of ideas, more confident speakers, increased interest in Shopify from some attendees, and a recurring pipeline in which storytelling generates further stories.
How Shopify Governs Containers at Scale with Grafeas and Kritis
Shopify describes using Grafeas and Kritis to govern container software across a platform handling more than 6,000 container builds per day and 330,000 images in its primary registry. Grafeas serves as a central store for metadata about container origins, builds, base images, layers, registry pulls, installed packages, vulnerabilities, and deployment status, supporting auditing and lifecycle strategies. During CI, audits produce attestations, which Shopify signs with PGP; Kritis uses named attestation authorities and Kubernetes policies to require specific attestations before deployment. Policies can require containers to be built by Shopify, sourced from a trusted repository, free of newly introduced vulnerabilities, tested, non-root, and deployed with the appropriate security context. Shopify also generates attestations from kubeaudit results for workload manifests, helping catch runtime-security regressions before deployment.
The Art of Hiring Good Engineers
Building and scaling engineering teams requires adapting recruitment strategies across different organizational sizes, from initial hires to hundreds of engineers. Teams often begin with small groups of battle-tested engineers before designing formal hiring pipelines. The recruitment approach outlines four key steps: sourcing top-tier talent from platforms like GitHub and LinkedIn, assessing technical fit through tailored screens or assignments, evaluating cross-functional and culture fit via group interviews, and optimizing the process. This optimization includes routing candidates strategically to strict bar-raiser interviewers to prevent burnout and expedite decisions.
Evolution of the Heroku CLI: 2008-2017
Between 2008 and 2017, Heroku's CLI evolved from Ruby (v1–v3) through Go/Node versions v4 and v5 to a pure Node v6 implementation. The rewrite addressed slower Windows performance, separation of the CLI's runtime from users' Ruby environments, migration to API v3, and limitations in Ruby-based plugin dependencies. V4 kept existing command syntax and output while adding features such as non-TTY color suppression and --json output; its Go core used Node for plugins, and the CLI became a collection of core plugins that could also be developed and installed independently. The team migrated commands incrementally, then added Flow, Babel, and improved tests, including Jest tests that run the flag parser. The resulting foundation supports modular, tested feature development, with cli-engine and more interactive interfaces planned.
So You Need to Hire Good Engineers
Hiring strategies in fast-growing technology startups dictate the quality and scalability of expanding engineering teams. Insights gathered from conversations with over one hundred engineering leaders identify crucial evaluation criteria across technical competence, cultural alignment, and problem-solving capability. Candidates rarely present a perfect technical fit, requiring hiring managers to weigh passion, willingness to learn, and risk appetite against baseline technical requirements. Rather than focusing solely on static factual questions, interviewers gain deeper insights by probing the rationale behind candidates' architectural and implementation choices. High-caliber engineers ultimately elevate team capability by simplifying complex challenges, writing cleaner code, and learning quickly.
Grab's Front End Study Guide
Rapid hiring and engineering expansion created a steep learning curve for newcomers and backend engineers unfamiliar with modern web architecture. Grab created an opinionated front-end study guide to help engineers navigate JavaScript tooling, state management, and modern application practices. The guide frames client-side single-page applications as a scalable alternative to traditional server-side rendering, enabling clear client-server separation for multiple client apps hitting the same backend API. It establishes core competencies in ECMAScript 2015 via Babel and explains how component-driven interfaces in React improve maintainability and performance through virtual DOM reconciliation. Ultimately, the resource aims to ramp up developer onboarding and accelerate shipping speeds across web platforms.
Driving Southeast Asia Forward with AWS
Grab transitioned its transportation platform from a single Ruby on Rails monolith on Amazon EC2 and Amazon RDS MySQL to a microservices architecture hosted on Amazon Web Services. The platform processes multi-petabyte real-time data flows and hundreds of millions of GPS data points to match drivers with passengers and push proactive demand heat maps. Operational efficiency is sustained with fewer than ten full-time infrastructure engineers, supported by AWS managed services. The analytics backend also transitioned from MySQL to Amazon Redshift, eventually moving to an Amazon S3 data lake using Amazon EMR and Presto. These data-driven matching systems improved driver-passenger allocation rates by up to 30%.
Deep Dive into iOS Automation at Grab - Continuous Delivery
Grab manages continuous delivery for its iOS applications using four build configurations per target: Adhoc QA, Hot Dogfood, Dogfood, and Testflight. The engineering team moved away from Fastlane in favor of custom bash scripts under 100 lines that execute clean builds and archives via xcodebuild. To eliminate manual logins for build execution, Grab developed a server-side Swift application integrating SlackKit and a bot named Iris. Incoming Slack commands are parsed and scheduled onto a serial DispatchQueue to trigger the appropriate build scripts. Deployment and rollback of updates to Iris and its build scripts are handled through Capistrano.
How Grab Hires Engineers in Singapore
Grab maintains a selective engineering recruitment process in Singapore, with only three to five percent of candidates ultimately receiving an offer. The evaluation pipeline typically spans three to four weeks and includes an initial HR phone screen, an online coding round, and consecutive technical interviews. Recruiters assess candidate capability via public GitHub projects, presentations, and technical blogs rather than traditional CV qualifications alone. The company prioritizes experience in low-latency distributed systems and microservices design alongside strong cultural alignment with peer collaboration.
Battling with Tech Giants for the World's Best Talent
Grab maintains research and development centres across Singapore, Seattle, and Beijing to develop mobility and transaction platforms for Southeast Asia. Engineer Brandon Gao turned down an offer from a major Seattle-based technology corporation to remain at the company due to rapid growth and high engineering impact. During backend infrastructure changes starting in May 2015, Grab transitioned core services from Node.js and Ruby to Golang. A weekend Golang prototype created by Gao evolved into the primary data service linking backend servers to 580,000 drivers across the region. Additionally, his initial work on the User Trust team established a machine-learning risk and fraud detection system supporting large-scale mobile transaction volumes.
Round-robin in Distributed Systems
Building client-side load balancing for Grab's Common Data Service prompted a move from AWS Elastic Load Balancers to DNS discovery due to persistent connection issues and unpredictable scaling events. After patching an open-source library that failed to rotate IP sequences properly, the author evaluated different Go patterns for round-robin routing. A mutex-protected array counter provides the simplest model for basic retrieval, though adding mutations requires careful lock coordination. Alternatively, a dedicated balancer goroutine receiving requests over nested channels enables explicit operation timeouts and centralized event handling at the cost of higher code complexity and channel creation overhead. The author recommends the mutex approach for resource fetching and the goroutine-based design for workload balancing.
Why Test the Design with Only 5 Users
Stakeholders often question whether qualitative testing with only five participants yields reliable design findings. The chosen research problem dictates the methodology, with qualitative usability evaluations requiring smaller cohorts than broad quantitative surveys. Jakob Nielsen's 1993 analysis demonstrated that testing with five participants uncovers 75 to 80 percent of usability issues, after which additional users yield diminishing returns. In agile environments, teams maximize efficiency by iterating designs across successive rounds of five participants rather than testing large cohorts simultaneously. This five-user threshold applies strictly to qualitative usability testing for specific feature flows rather than opinion gathering, A/B testing, or multi-segment user analysis.
Programmers Beware - UX is Not Just for Designers
Software engineers frequently overlook user experience when designing APIs, SDKs, and code-level functions. Usability issues arise across various technical interfaces, from mobile apps forced to coordinate multiple round-trip network calls to ambiguous function signatures that obscure boolean arguments. To counter this, engineers can apply a five-question discovery framework to identify user identity, core objectives, user capabilities, ways to reduce user burden, and familiar paradigms. Practical remedies include sacrificing strict RESTful separation to merge mobile endpoints, placing validation logic inside internal RPC servers, and replacing boolean arguments with explicitly named helper functions. Ultimately, treating calling systems, end users, and fellow programmers as users shifts implementation complexity from consumers to servers.
Heroku Metrics
Heroku’s original Dashboard Metrics system stored 10-minute rollups in a 21-shard InfluxDB cluster, but new requirements for one-minute data, richer events, extensibility, and failure tolerance exposed infrastructure limits. To replace it, the team built a Kafka-based pipeline on Private Spaces: an ingress app parses Logplex frames into Protocol Buffers messages, Go consumers aggregate measurements into one-minute summaries, and a sink writes rolled-up data to seven sharded, partitioned Heroku Postgres databases. The custom Yahtzee framework uses accumulator maps for counts and streaming min, max, and sum calculations with deterministic partition ownership; late data and aggregation-process restarts were implementation hurdles. The design reduces reliance on expensive InfluxDB continuous queries and makes adding another datastore straightforward, although Postgres performance remains merely acceptable and measurements can still be lost before Kafka because the logging pipeline is lossy by design.
Speeding Up Sprockets for Faster Asset Pipelines
The Rails asset pipeline can take over 20 times longer than dependency installation because Sprockets consumes memory, disk I/O, and CPU while reading, fingerprinting, compressing, and resolving dependent assets. Reusing its disk cache failed across Capistrano releases and Heroku builds because cache keys and dependency data embedded absolute paths, so identical files appeared different when compiled from changing directories. Sprockets 3.3+ addresses this with UnloadedAsset, normalized relative cache keys, and URITar, which compresses paths and URIs before caching and expands them when loading; Windows portability was fixed in 3.3.4. In an example app, the initial compile remained about 38 seconds, while the second took 3 seconds, a roughly 1,200% speed increase when compiled assets were reused.
Incremental Garbage Collection in Ruby 2.2
Ruby 2.2 introduces RincGC, an incremental garbage collector intended to reduce the long pause times that Ruby 2.1’s generational collector could produce during major GC. The approach splits marking into fine-grained steps interleaved with Ruby execution, while lazy sweeping remains incremental; because CRuby lacks sufficient write barriers, unprotected objects are rescanned before white objects are reclaimed. The article explains the white, grey, and black object model, the write-barrier safety problem, and uses GC::Tracer events with a Rails benchmark simulating 30,000 requests to measure pauses. In the reported measurement, generational GC produced seven large pauses with a maximum of about 15 ms, while incremental GC reduced the maximum to around 2 ms, without reducing total GC time or improving throughput.
Debugging Super Methods with Ruby 2.2
Ruby exposes method metadata and caller-stack information, but before Ruby 2.2 it was difficult to identify the method ultimately reached by super, especially in metaprogrammed code. The example defines Dog#bark and SchneemsDog#bark, then extends an instance with DoubleBark, whose bark method calls super twice; inspecting the class hierarchy incorrectly reports Dog#bark because the module is not an ancestor of the instance's class. Ruby 2.2 adds Method#super_method, a feature proposed in request #9781 and accepted into the Ruby trunk, which returns the method Ruby will invoke for super, including the correct SchneemsDog#bark in this case. Calling source_location on that returned Method provides the location of the actual implementation and avoids the custom metaprogramming previously needed to trace it.
Short Time Outs and Asynchronous Requests on Heroku
Heroku’s short request timeout and H12 errors reflect a scaling problem: standard web servers process queued requests serially, so one long operation can block others. The post separates slow server-side actions, such as video processing or PDF generation, from file uploads, and recommends background processes for the former and direct browser uploads to Amazon S3 or Google Cloud Storage for the latter. When a client must wait for completion, it describes polling or a WebSocket, noting that WebSocket connections close after 55 seconds of inactivity and ordinary pages still need to respond within 30 seconds. Avoiding lengthy web-process work improves performance and scalability; rack-timeout for Ruby or expressjs’ timeout for Node can terminate requests after a few seconds, with a recommended limit no higher than 10 seconds.
Instrumentation by Composition
Instruments is a Go library for collecting application metrics over discrete time intervals, including request rates, latencies, data-structure sizes, and event durations. It supplies Counter, Rate, Reservoir, Gauge, Derive, and Timer instruments; values represent only the latest time-window and are read through a single-reader Snapshot operation. Composition is central: instruments implement either Discrete, returning one int64, or Sample, returning a slice, so custom instruments can wrap existing ones; the example embeds a Reservoir in an http.Handler to record upload request sizes. Derived instruments build on this model, with Derive using Rate and Timer using Reservoir, while Quantile, Mean, and reporting utilities process snapshots. An optional registry and logfmt reporter support periodic output, but applications can also send selected values to systems such as Graphite or use them for control signals.
Top topics
- Architecture834
- Performance817
- LLMs673
- Machine Learning622
- Open Source568
- AI Agents564
- AI483
- Developer Experience448
Weekly digest
The best engineering reads, once a week.