That was the framework; This post is about building an actual app on top of it. Where we left off, I teased that the end goal was porting my THREE.js dice roller to this little device. The web version uses a browser’s GPU, a physics engine written in JavaScript, and environment lighting from an HDR panorama. The MMF has none of those luxuries. The question was: how much of that visual quality could survive the translation to a CPU-only ARM chip?

More than I expected, it turns out.

Defining the dice: platonic solids in code

The first job was describing the dice in a language the renderer understood. The web version had this in JavaScript; I translated it into a C++ header file.

A die is a platonic solid: a shape where every face is the same regular polygon. The d4 is a tetrahedron (4 triangular faces), the d6 a cube, d8 an octahedron, d10 a pentagonal trapezohedron, d12 a dodecahedron, and d20 an icosahedron.

These “-hedron” words took me right back to the crystallography course I took in undergrad when I was studying nanomaterials. I have to say, it’s considerably more entertaining to encounter icosahedra and dodecahedra in a tabletop games context than in crystal lattice diagrams.

static const DiceDef DICE_DEFS[NUM_DICE_TYPES] = {
    { "d4",  4, /* scaleFactor */ 1.20f, /* invertUpside */ true,  ... },
    { "d6",  6, 0.90f, false, ... },
    ...
    { "d20", 20, 1.00f, false, ... },
};

Each DiceDef stores the "canonical" vertex coordinates (typically in a −1 to +1 cube), a scale factor to make all dice look visually proportional, and the faces as ordered lists of vertex indices. The face ordering, called winding order, determines which side is the front. Get it wrong and the die looks inside-out.

The d4 is weird

The d4 has two common designs: top-numbered (you read the apex vertex) and bottom-numbered (you read the face resting on the table). The THREE.js version was top-numbered, since it placed digits on the three vertices surrounding each face. That was a natural fit for a high-resolution screen.

On the MMF’s 750×560 framebuffer, squeezing three numbers onto a tiny triangular face looked terrible. So I switched to a bottom-numbered design in this C++ port: you read the face pointing downward, and the die stores a single centered digit per face. The invertUpside = true flag tells the face-detection code to look for the face whose normal points most downward, not upward. More on that when we get to face detection.

Making them fall: Bullet3 physics

A dice roller without physics is just a random number generator with a pretty skin. I added Bullet3 for the simulation.

There is actually a genealogical thread connecting the THREE.js version to this one. The web dice roller used cannon.js for physics — and if you follow cannon.js back through its ancestry (like I did in the side note of this blog post), it is a JavaScript port of… Bullet. So in porting the dice roller to C++, we are paying tribute to the original ecosystem by returning to the source.

Bullet3’s job is straightforward: each die is a rigid body — an object with mass, position, rotation, and velocity. Every frame the engine advances the simulation by one timestep. It applies gravity, finds where bodies overlap (collision detection), and resolves those overlaps with realistic contact forces (bounce and friction).

For collision detection, Bullet uses a convex hull of each die’s vertices. Because all platonic solids are convex, this is exact — not an approximation. It’s also the fastest possible collision shape Bullet supports[1]. The scene is thus minimal:

• One infinite flat plane (the floor, mass = 0, static)
• Up to 12 convex-hull rigid bodies (the dice, mass = 1)

Spawning a throw means placing each die above the table at a random position, giving it a random rotation and some angular velocity, and letting Bullet take over:

d.body->setAngularVelocity(btVector3(RandF(-8,8), RandF(-8,8), RandF(-8,8)));
d.body->setLinearVelocity (btVector3(RandF(-2,2), RandF(-1,1), RandF(-2,2)));
world->addRigidBody(d.body);

The floor and dice exist twice in the codebase: once as Bullet collision objects, and once as Raylib geometry for rendering. The physics floor is an infinite mathematical plane; the visual floor is a textured quad. They share the same ground height so dice don’t visually float above where they land.

Detecting when a die has settled — and reading the result

The JavaScript-based threejs-dice library takes an interesting shortcut with outcomes: you can prescribe which number each die will show before throwing. The trick is clever: let the physics simulation run to completion in an instant (which is much cheaper than the rendering 3D), observe which face landed up, and then paint the desired number onto that face. The rendered trajectory is real; only the paint job is rigged.

This C++ port takes a more authentic approach: both physics and rendering happen frame-by-frame, simultaneously. There is no “run ahead” — the simulation and the visuals are always in sync. I did vibe-code a “rig mode”[2], but it works after settling, by physically rotating the die to face the target upward. No post-effect paint job.

After throwing, the game polls each die every frame for stillness:

bool IsDieSettled(const ActiveDie& d) {
    btVector3 v = d.body->getLinearVelocity();
    btVector3 w = d.body->getAngularVelocity();
    return v.length() < 0.3f && w.length() < 0.3f;
}

A die is “settled” after it has been nearly motionless for 30 consecutive frames (~1 second at 30 FPS). Only then do we read its face-up value.

Face detection works by examining the die’s current rotation. For each face, we compute its outward normal (a perpendicular vector) and take the dot product with the world up-direction (0, 1, 0). The face with the highest dot product is pointing most skyward — that's the face you rolled. For the d4, invertUpside = true flips the query to (0, −1, 0), finding the face closest to the ground.

The rendering pipeline: ten layers, painted back to front

With positions coming from Bullet and geometry from the definitions, the renderer’s job is to turn all of that into pixels. The pipeline draws ten layers every frame, strictly in this order:

1. Skybox — the background
2. Floor — the pre-lit hardwood quad
3. Reflections — semi-transparent upside-down copies of the dice
4. Shadows — dark silhouettes projected onto the floor
5. Dice faces — translucent, shaded geometry
6. Number decals — digit textures painted on each visible face
7. Edge wireframes — subtle white outlines
8. Scratch overlay — fine surface scratches lit in real time
9. Bloom halos — specular glow (off by default; explained later)
10. Post-processing — per-pixel bloom boost + depth fog

Order matters a lot here. The dice are semi-transparent, so the GPU’s depth buffer can’t sort them — that only works for opaque objects. Instead the renderer sorts all dice back-to-front before drawing (the painter’s algorithm) and disables depth writes during the dice pass to prevent Z-fighting with the overlays.

Shadows and reflections

Two of the most grounding effects — things that make the dice feel like they exist in a real space — are the projected shadows and floor reflections.

Projected shadows work by “flattening” each die onto the floor along the key light direction, like tracing a silhouette cast by a flashlight. For each die, we interpolate a ray passing each vertex to the floor, compute the convex hull of the projected points, and draw it as a dark polygon. The opacity fades as dice hang higher in the air, so that falling dice cast paler shadows than ones resting on the table.

Edges further away from the floor should, in reality, cast fuzzier shadows. Unfortunately, blurs are too heavy to compute without a GPU. To mimic the effect, we draw a penumbra, which is a second, slightly larger and more transparent polygon around the outer edge. It fakes the soft falloff at the shadow boundary. But it looked too fake (since we can’t do blurring — more details later), so I turned it off by default.

Floor reflections are drawn as an upside-down, y-flipped copy of each die, slightly transparent and blended into the floor surface. That’s not a reflection in the optics sense, not even the “planar reflection” trick you’d find in early video games (where you’d place another camera in the “mirror world”). Instead, it is literally the same polyhedrons drawn with scale.y = -1 and reduced alpha. The cheap trick works because the floor is flat and the camera is never below the surface.

Lighting: a studio in a header file

Real-world photography and film use a “key + fill” lighting setup. The key light is the main, bright source that creates defining shadows and highlights. The fill light is softer and comes from the opposite direction, preventing shadows from going pitch black.

Note that in my older THREE.js implementation, the fill light was implemented as an ambient light, which has no direction. In this Raylib implementation, however, both lights are directional. Conceptually, the two lights are infinitely far (like the sun), so we only need one unit vector to describe their direction. Thus, lighting a vertex is a dot product: a surface facing the light is bright; one facing away is dark.

I chose to make the fill light directional this time because I wanted to try something else with the environment lighting. In the JavaScript edition, THREE.js was able to use the brightness channel in a HDR photo for luminance from the skybox. I never studied how THREE.js implemented it, but since TinyGL doesn’t support it anyway, I wanted to try an approximation called Spherical Harmonics (SH) this time.

SH is a mathematical compression of the light coming from all directions[3]. At “level 2” (L2), SH captures:

• (L0) the overall brightness,
• (L1) which direction is brightest, and
• (L2) broad color variation across the environment,

using just 27 floating-point numbers. At runtime, evaluating the SH for a given surface normal is just 9 multiplications & additions, which is blazing fast. The coefficients are computed from the skybox image at build time using cmgen, so the device never has to process the panorama at runtime.

To be candid, I put SH in for fun more than for visual effects. The “photo booth” skybox I used is too monochromatic to provide much color variation. The ambient contribution is subtly nice but nothing to write home about. I was curious about how the concept worked in a totally different context, as the first time I learned about SH was in a quantum mechanics class back in college. In that context, SH described the spatial probability distribution of where an electron is likely to be found in atoms. I can’t say which is more mentally demanding, atomic physics or computer graphics.

The glass look: Fresnel and near-invisibility

The dice are modeled after glass polyhedra. Real glass is nearly transparent when you look straight at it, but becomes mirror-like at glancing angles. That’s the Fresnel effect. It is one of the defining visual signatures of glass and water.

The Schlick approximation[4] gives a cheap formula: F ≈ F₀ + (1 − F₀)(1 − cos θ)⁵, where θ is the angle between the surface normal and view direction, and F₀ ≈ 0.04 for glass with an index of refraction of ~1.52.

The base opacity of each die face is set to DICE_ALPHA = 12 — essentially invisible. Fresnel then boosts the opacity at silhouette edges up toward full opacity. The result is a die that looks like a solid object at its edges but nearly disappears when you look at its face head-on.

This same Fresnel term also drives a rim glow at silhouette edges. A Blinn-Phong specular with a tight power-16 exponent creates the shiny hotspot. A clearcoat layer (power-32) adds a secondary, even tighter gloss. With a bit of tessellation[5] on the faces, the combination gives the dice a convincing polished-glass appearance, with zero ray-tracing.

The skybox: a cylinder you live inside

The web version used a proper spherical panorama for the skybox. OpenGL 1.1 has no concept of a cubemap or a sphere with infinite distance. So the skybox is faked as a large cylinder textured with horizontal strips sliced from the original panorama.

To avoid visible seams, the panorama is pre-sliced at build time into 8 tiles[6], and each tile is loaded as a separate TinyGL texture at startup. The cylinder uses clamped wrapping at the top and bottom edges to prevent smearing.

This is a good example of working with constraints rather than against them. Rather than trying to hack infinite-distance geometry into TinyGL, the fake just needs to be big enough that no die ever leaves its interior.

Things we can’t do

So far, we’ve been talking about effects that we managed to squeeze into this little handheld, one way or another. Unfortunately, there are things that simply can’t fit into the package.

Refraction

Real glass bends light passing through it. A proper refraction effect would require either rendering the scene twice from different angles, or a screen-space trick where each pixel samples the framebuffer at an offset proportional to the surface normal. Both require reading from the framebuffer at arbitrary positions — something that is expensive on a CPU rendering into a fixed buffer, and that TinyGL’s OpenGL 1.1 interface does not support. Refraction stayed on the cutting room floor[7].

Refraction is expensive and hard to get right. Even in the THREE.js-based implementation, if you look closely into the banner image of my repo, you’ll see that refractions are not compounded: Looking through both the D6 and the D4 in front of it appeared as if you are just looking through the D4 itself. It’s a major giveaway in this otherwise photorealistic render.

Material capture (matcap)

Initially, I wanted to employ a matcap. It’s a technique that fakes environment reflections using a lookup texture photographed from a sphere. When rendering, you compute the surface normal in camera space, use it as a 2D UV coordinate, and sample the texture. The result would look very convincing and cost almost nothing at runtime.

The problem: I wanted the camera to be rotatable. A matcap is essentially a photograph taken from one viewpoint; it only looks correct from that exact angle. As soon as the camera moves, the “reflections” don’t follow the environment — the surface looks painted-on. The Fresnel + specular approach is slower but correct for any camera angle.

Anything that involves blurring

Real shadows rarely have defined boundaries. Reflections on wood plates shouldn’t look as sharp. Highlights would also have a dream-like glow, known as the bloom. All three effects would need some blurring computation to simulate, which is really tough on a CPU.

To blur a pixel, we need to know what its neighbors look like. Meanwhile, TinyGL’s glPostProcess callback delivers one pixel at a time with no API for reading neighbors. Implementing a blur ourselves would require a second framebuffer allocation and bypassing the callback entirely. But a separate framebuffer is exactly the bottleneck we eliminated by replacing rlsw with TinyGL in my previous post. My coding agent estimated a 15~50x demand in compute, depending on the quality we want. I would rather forego blurring in favor of a usable frame rate.

Going faster: Optimizations

At 30 FPS on a 1.5 GHz dual-core Cortex-A7, every cycle counts.

SIMD vertex transforms

Every frame, each die’s vertices must be transformed from local coordinates to world coordinates using a 4×4 matrix. Instead of processing one vertex at a time, the code processes four simultaneously. This was possible because the CPU has an extension for “single instruction, multiple data” (SIMD) operations, named ARM NEON. By providing flags like -mfpu=neon-vfpv4 in our build script, we are already telling GCC to optimize floating-point computations with it.

Beyond that, we can use the NEON intrinsics to hand-roll our own optimizations. To do that, we organize the data in a Structure-of-Arrays (SoA) layout by separating contiguous arrays for x, y, and z. With this arrangement, a single vld1q_f32 instruction loads four consecutive x-values at once:

struct alignas(16) V3Batch {
    float x[MAX_DIE_VERTS];
    float y[MAX_DIE_VERTS];
    float z[MAX_DIE_VERTS];
    int n;
};

The same SoA layout powers the scratch overlay rasterizer, which bypasses TinyGL entirely. OpenGL 1.1 has no fragment shaders, so TinyGL’s per-face lighting is uniform across a face, and you can’t vary a value per pixel. The fine scratches on a glass surface need per-pixel bump lighting that responds to the die’s current rotation. The solution was a custom scanline rasterizer that walks the framebuffer pixel-by-pixel, samples a normal map, and computes the tangent-space dot product on the fly using NEON at four pixels per cycle.

Build-time asset baking

A separate “prebake” tool runs on the x86 build host inside Docker before any ARM code runs. It pre-computes:

1. The SH lighting coefficients (emitted as prebaked_sh.inc, a C header included at compile time)
2. The floor texture (lit and specularly highlighted per pixel, once, at build time)
3. The eight skybox tiles (pre-resized to 256×256)

This turns boot time from “several seconds of computation” into “load some PNG files”.

The number atlas: 21 glyphs in one texture

To show numbers on die faces, the renderer draws a small textured quad floating 0.005 units above each face surface. Switching textures per draw call is expensive, so all 21 glyphs (0–20) are packed into a single 256×256 texture atlas at startup. (You might have heard of a special case of this technique: sprite sheet.) When face “17” needs its decal, the code computes the atlas UV:

int col = value % 4, row = value / 4;
*u0 = (float)(col * 64) / 256.0f;  // left edge
*u1 = (float)((col+1) * 64) / 256.0f;  // right edge

Multi-digit numbers get special treatment: each character is placed at a fixed spacing based on the widest digit (“8”), so “12” doesn’t look cramped. Each glyph is drawn three times with 1-pixel offsets to fake a bold/shadow effect, since Raylib’s built-in font produces thin strokes.

The result

The final binary runs at 20 FPS on the MMF with up to 12 dice simultaneously: d4, d6, d8, d10, d12, and d20 in any combination. It includes reflections, shadows, a glass shading model, number decals, surface scratches, a skybox, and a live-tunable settings panel with 18 parameters (IOR, rim strength, specular, clearcoat, shadow softness, and more).

The codebase, tslmy/raylib-on-miyoo-mini-flip, is ~2,500 lines of C++ spread across eight source files. The binary is about 6 MB. Boot time on device is under five seconds. The full build — including Docker, cross-compilation, and asset prebaking — runs in roughly three minutes on a modern laptop.

This dice roller was vibe-coded, though I try to understand at least what each component does. There are many interesting parts I have to leave out, such as procedurally-generated norm maps for bumps and scratches. It was really impressive that AI agents could pull those off, but they simply didn’t fit the theme of “squeeze as much graphics as possible from a $60 handheld”, so I had to leave them out from this long article.

I hope you enjoyed learning the art of computer graphics with me. Building a practical utility program for an limited platform gave me great sense of achievement, and I wish you would find it inspiring for your own side projects. Until next time!

1. The GJK (Gilbert–Johnson–Keerthi) algorithm computes the distance between two convex shapes in amortized constant time for typical inputs, making it the fastest collision detection Bullet offers.
2. Controlled by the RAYLIB_MMF_RIG environment variable in launch.sh. The B button cycles through rigged values.
3. SH are a set of mathematical functions defined on a sphere — analogous to Fourier basis functions in 1D. “L2” means we keep terms up to degree 2, giving 9 basis functions. Each captures a different spatial frequency of the lighting environment: L0 is constant (average brightness), L1 varies linearly across the sphere (which direction is brightest), and L2 captures the next level of variation. The full derivation is in Ramamoorthi & Hanrahan 2001.
4. Christophe Schlick, “An Inexpensive BRDF Model for Physically-based Rendering”, Eurographics 1994.
5. Required since we use Gouraud shading to avoid per-pixel work. Otherwise, the faces would appear to have their opacities on linear gradients from corner to corner.
6. Each is resized to 256×256, which is the original TinyGL’s only texture size. The fork I use seems to have made it configurable, but I have not tried.
7. Screen-space refraction is feasible in some OpenGL contexts using glCopyTexSubImage2D to sample the scene behind the surface — but at ~1 ms per texture copy at 750×560, doing it per-die per-frame on a CPU renderer was not going to happen.

Game Boy Advance (GBA), a handheld from 25 years ago, is one of homebrewers’ favorite target platform. Earlier this year, I dabbled in this hobby by hacking an idle game created in 2023. As it was perhaps apparent in my previous post, that was my first exposure to game development.

One may ask: What if you want to learn to make games, but aren’t feeling too nostalgic? Raylib is usually the answer. It’s a cross-platform framework that aims at putting fun into video game development. And it’s popular: on itch.io alone, more than 700 games are made with Raylib.

Won’t it be exciting to port Raylib to those budget handhelds, so that those developers can enjoy their creations on more tangible, dedicated gaming devices — with joy sticks, D-pads, and everything? This shouldn’t be hard, since many of those retro gaming handhelds run some kinds of Linux. To make it more interesting, I decided to raise the bar and aim at rendering 3D scenes.

First iteration

I started with the Miyoo Mini Flip (MMF) that I bought in March. It presented an exciting challenge[1]:

• The SSD202D SoC (dual-core ARM Cortex-A7) has no 3D GPU.
• EGL/GLES libraries are on disk, but eglInitialize failed.
• The Simple DirectMedia Layer (SDL) library, which I highly regard, couldn’t create a GL context on MMF.
• The only hint I could find is /dev/fb0, which represents the framebuffer[2].

But besides /dev/fb0, MMF's Linux gives so little on the graphics stack that, had the OS been absent, it probably wouldn't make a difference at all.

It’s funny that, only 4 months before I started this project, Raylib actually started adding support for OS-less situations. Referred to as PLATFORM_MEMORY in the makefile, this configuration draws directly to the framebuffer. This is almost exactly what I needed. I just needed to wire it up with /dev/fb0. The plan is thus:

1. Render the next frame in the program’s memory space
2. Copy that frame into /dev/fb0
3. Tell the display to “flip the buffer”[3]

Coding agent soon gave me a workable build script. But unfortunately, even when it’s as rudimentary as a spinning cube, the scene can barely surpass 7 FPS on my MMP:

Swapping the software renderer

PLATFORM_MEMORY requires that we use a software renderer, which by default wires to Raylib’s own rlsw. This young library renders into its own internal framebuffer, then you must call glReadPixels (via rlCopyFramebuffer) to transfer it to system memory every frame. I could confirm that it was the bottleneck: When I skipped the copying step (so the frames are rendered but never sent to the display), the FPS jumped to 25 FPS immediately.

Fortunately, rlsw implements OpenGL 1.1. This version was released in 1997, when 3D rendering still heavily relied on CPUs. Even GPUs were, quoting Reddit, “often actually an esoteric CPU running a software rasterizer.” Therefore, this legacy edition has long been a popular target for software-based renderers. To us, this means there are replacements.

One of such replacements is TinyGL, which debuted in 2002. Compared to rlsw, which was introduced only in 2025, TinyGL had more time to polish. Most prominently, it renders directly into platform.pixels, so there's no memory copy involved. I decided to swap rlsw with TinyGL.

To make them cooperate, I had to patch both TinyGL and Raylib, in addition to some build-time wiring & stubbing. Finally, it was time to switch the RAYLIB_GRAPHICS flag -- We gave something to Raylib that is so mature and usable that we could switch it from "use the built-in software rasterizer" (GRAPHICS_API_OPENGL_SOFTWARE) to "use a provided OpenGL 1.1 API" (GRAPHICS_API_OPENGL_11). It felt like a great achievement.

The result speaks for itself: Frame rate jumped to 25 FPS.

What’s next?

I plan to write about how I managed to port my dice roller from THREE.js to this little device, which I teased about in my previous post. Although we are only half way there, this is a good point to take a pause: Compared to a journey of how a specific app is built, the proof that a whole framework can run on budget gaming consoles will inspire more readers.

I hope you are one of them. If you have a made something with Raylib and only played it on a computer, try putting it on a cheap handheld. It will feel different in your palms — I promise.

1. Snippets of probe programs, their console logs on MMF, and more notes are available here.
2. The framebuffer is a region in the memory, but a Linux kernel driver exposes at /dev/fb0, as if it's a separate device. This virtual device is often referred to as "FBDEV".
3. A prober program told me that this framebuffer is actually double the size of the actual display (actual 640x480; virtual 640x960). This means we are dealing with a double buffering situation, requiring us to “pan the display” from one buffer to the other upon every frame (using FBIOPAN_DISPLAY).

That’s true — but it’s also underselling it.

SDL is better understood as a Platform Abstraction Layer (PAL) — a role much closer to what a browser runtime plays on the web. Both sit between your code and the platform. Both smooth over fragmentation. Both define what “portable” means in their domain.

Once you see it that way, a lot of things click:

• why SDL looks the way it does
• why it never became “the web for native apps”
• and why it quietly powers much of today’s WebAssembly ecosystem

Let’s unpack that.

What it is

SDL abstracts away differences across operating systems in accessing audio, keyboard, mouse, and graphics hardware. Notable “subsystems” include:

A higher layer of abstraction than operating systems

While an OS abstracts the specific hardware (so you don’t care if it’s a Seagate or Western Digital drive), SDL abstracts the OS-specific abstractions themselves.

It’s also important to recognize where the abstraction “leaks”.

There are a few things that SDL doesn’t cover in Operating Systems’ “personality”.

• You are still compiling against different ABIs. (Building your software with SDL doesn’t magically make your Windows binary executable on a MacBook.)
• If file operations are required, file systems and directory structures can still be a “gotcha”.

Also, there are hardware design philosophies that SDL just can’t completely hide. For example, the Application Life Cycle (init, quit, etc.) works differently on a smartphone. Mobile OSs (iOS/Android) can “pause” or “kill” your app at any time to save battery. This means:

• In a standard desktop SDL app, you might just loop until a “Quit” event.
• On mobile, you must listen for specific events like SDL_APP_WILLENTERBACKGROUND to save your state immediately.

Web technology is another PAL

In systems engineering, such technologies are called Platform Abstraction Layers (PALs)[1]. A more popular PAL is today’s web technology. In many ways, SDL is roughly the “native” equivalent of the Web Browser’s runtime.

If you look at the architecture, the comparison is almost one-to-one:

Since SDL generally abstracts at a lower level than browser engines do, it’s completely possible to stack these two layers. Announced in 2008, Origyn Web Browser (OWB) did exactly that. This comment from an OWB developer back then showed us what role people think SDL serves best in between all these abstraction layers:

our first goal is to provide a better abstraction layer to webkit to ease webkit
portage and our reference implementation is SDL

Why SDL didn’t become “The Web”

In an alternative universe, SDL would be the “thin client” everyone installed. The reason the Web won the popularity war comes down to three things SDL doesn’t do.

Most intuitively, web content is much easier to deliver to end users. Web apps are JIT-compiled (JavaScript/WASM) and streamed. SDL apps must be compiled specifically for the target CPU architecture (x86, ARM) and downloaded as an executable.

At the other end of the product cycle, the Document Model (DOM/CSS) speeds up value creation. When SDL gives you a blank canvas, the Web gives you a high-level layout engine (think: Bootstrap, Flexbox, etc.). In SDL, you have to manually calculate where every “div” goes.

Combining the “delivery model” and the “document metaphor”, we can see why web browsers must adopt a tighter security model:

• When you knowingly install a program, you imply that you approve its effects[2]. You’re committed to it, to some extent.
• But if you are just reading a document (i.e., webpage), you shouldn’t be manipulated by whatever malicious instructions written on it. Reading a flyer doesn’t automatically sign you up for that fitness class.

Thus, modern browsers are secure by design. They run untrusted code from the internet safely, using technologies like sandboxes. On the other hand, SDL apps are native binaries; they have largely unrestricted access to your system.

In short: easier consumption for end users, faster value creation during development, and better safety measures.

The Modern Intersection: WebAssembly (WASM)

The irony is that these universes have actually collided. Because SDL is so good at abstracting hardware, it is one of the primary ways people port native C/C++ games to the web today.

The primary mechanism for this porting is Emscripten (how), a compiler toolchain that leverages SDL to bridge the gap between native code and the browser.

When you see a complex 3D game running in a browser tab, it is almost always an SDL codebase that thinks it’s talking to a graphics card, but SDL is actually “translating” those calls into WebGL and Browser APIs.

In that sense, SDL has quietly become the bridge that lets the native world masquerade as the web.

SDL never became “the web for native apps”, but it didn’t need to. Instead, it became the thin layer that makes the native world portable enough — including into the browser itself.

And that’s a more interesting fate: not replacing the web, but quietly enabling the two worlds to converge.

Games: the elephant in the room

All of this abstraction talk might sound general-purpose — but in practice, SDL’s center of gravity has always been gaming. Some people even claim that SDL was specifically created to facilitate game development from the start.

Big names use SDL. Both Unreal Engine and Unity utilize SDL on Linux. To me, SDL is the unsung hero like XKCD 2347 depicts, minus the “maintained by just one person” part.

Interestingly, neither game engine appears to use SDL on Windows. Was it mostly informed by a budget concern in development[3], a need for heavy optimization on Windows itself, or just a legacy / tech debt that predates SDL? I don’t yet have an answer.

Another fact that I wasn’t aware of is Valve’s stewardship in SDL. Gemini says:

Valve’s Source Engine and Source 2 are arguably the most prominent “heavyweight” users of SDL in the industry. While Unreal and Unity use it for specific platforms, Valve has integrated SDL into its core DNA to drive its push for Linux and the Steam Deck.

Valve doesn’t just use SDL; they help build it. This allows Valve to upstream features specifically needed for their hardware, like Steam Controller support and Steam Deck optimizations. One of the lead developers of SDL, Sam Lantinga, is a Valve employee.

This ties back to why I wrote this

I bought a “retro gaming handheld” recently, and it runs Linux, so I wanted to see what I can build for it. Cross-compiling TUI programs like htop didn't take me too long, so I challenged myself with something with a GUI. I found two good examples:

• MiyooPod: a MP3 player. In Go.
• RetroDex: a pokédex. In C++.

Both use a library called SDL. Had not heard of SDL before, I spent some time orienting myself in its ecosystem, hence this article.

The end

I started this journey just trying to build something for a tiny Linux handheld. What I didn’t expect was to stumble into a layer of the stack that quietly connects desktop apps, game engines, and even the modern web.

SDL sits in that strange middle ground — low-level enough to feel like native code, but abstract enough to travel across platforms, even into the browser. That tension is exactly what makes it powerful — and occasionally frustrating. I’ll explore both in the next post.

1. Or you may say SDL is a type of Cross-Platform Support Middleware (CPSM), but the difference between PALs and CPSMs is another rabbit hole that deserves its own post in the future.
2. To some degree, at least; runtime security features like User Account Control are relatively recent inventions.
3. Either “diversity in hardware that can run Linux calls for an additional abstraction layer”, or “Linux gaming wasn’t popular enough to justify more dedicated efforts into its low-level programming”.

Or a journal of AI failure modes

A Hacker Dojo meetup showed me how big the hobby “retro video gaming” is. Having completed a few GBA titles (Pokémon Ruby and The Urbz: Sims in the City fans, anyone?) back in elementary school, I bought myself a Miyoo Mini Flip (MMF) to revisit the good old ages.

The dawn of a side project

Being a software engineer, I entertained the idea of tinkering with it more than just gaming on it. The first thing I looked into was homebrew GBA ROMs. I needed an example to learn from, and the idle game Sips was a good fit: It’s written with only a few hundred lines of C++ code, and it’s built upon a modern GBA gamedev framework called Butano.

Sips is a cozy game that simulates a coffee shop with customers. They walk into your cafe, line up, buy stuff, and leave. One thing can be improved: Not everyone walking past your storefront will patronize your business. “Passers-by” sounded like a behavior that I can add to the game comfortably.

The enter-buy-leave logic was implemented as a finite state machine (FSM). My day job, which revolves around stateless web services, didn’t expose me a lot to FSMs, but it did teach me to run tests before modifying someone else’s code. So I looked for them. As one may expect from a GameJam product, there wasn’t any. That’s fine; I said to myself, I can add tests for them.

That’s where the rabbit hole began. You see, I barely had any experience in cross-compilation, and I’m too spoiled by mature, “de facto standard” testing frameworks like pytest and JUnit. The platform where I run tests is where I’ll be running production code. But this parity often won’t hold in embedded development: If I wanted to utilize familiar, generic frameworks (like Catch2) in tests, I should run them on my host machine, leaving the ROM with pure game logic.

Adding tests for a GBA ROM

But GBA headers (from Butano) won’t run on a MacBook. To reduce the import footprint to only the bare minimum, I had to extract functions from the monolithic main.cpp to helper files (example). This side effect was satisfying, as I prefer a more modularized codebase.

However, my experience wasn’t as positive with the pathfinder algorithm. Specifically, I wanted to add test to the get_next_step function. Its original implementation relied on trigonometric functions like sin and cos. On GBA hardware, Butano provides a method for both of them degrees_sin_and_cos, but it won't compile on a Mac. So I asked GitHub Copilot what to do.

The first solution it proposed was to stub out Butano math. That added ~100 LoC in stubs just to power ~30 LoC of test cases. I’m sure it would have been the right thing to do, had I planned to add so many tests (think: 500 LoC) that they would amortize away the cognitive cost of these stubs. But that really wasn’t the case; I was just trying to get comfortable with ROM hacks before I move on to other MMF tinkering ideas. This isn’t a serious software engineering project that I intend to maintain for years.

So I created a new session. I told Copilot that I’d rather use std::sin and ::cos, but GBA doesn't have <cmath>. This time, the solution was utterly AI slop: It used a macro that switches to an entirely different implementation for get_next_step during tests. Perhaps the way I mentioned <cmath> was misleading; AI seemed to think that "the user wants to make use of <cmath> at all costs", or "the goal is to make use of <cmath>". This behavior is reminiscent of junior developers who would fixate on introducing a specific technology just for the sake of using it. It further makes me think: maybe the training data inherently biases LLMs towards Résumé-Driven Development (RDD) -- "Wow, you know how to use that? Nice. Now reinforce!"

Use real `butano`; remove stubs. · tslmy/sips@dde8730

This ugly situation wasn’t addressed until I got comfortable with the source code enough to ask the AI “what optimizations can you think of”. This time, it rewrote the get_next_step function with approximations that avoid trigonometric functions entirely. At last, we can run the same pieces of code across testing and playing now.

What came next

From there, I was able to add a few realistic behaviors to the NPCs:

• They may simply pass by, not coming in for a drink.
• They may loiter on the street for a short while.
• They avoids running into each other.

And to visually inspect the FSM, I added a “highlight” mode to the gameplay. When you press L+R together, a customer will be selected, and his/her live state will be printed at the bottom of the screen. Pressing L/R will cycle the cursor around all customer on screen, and another L+R combo brings you back to the “sit back and watch” mode. This gave me a strong intuition about how FSMs are used on NPCs in video games, to a point that, if I were to teach a gamedev course, I’ll use this ROM as an apparatus.

This side project soon has finished serving its purpose. I moved on to look at cross-compiling other stuff for the MMF. To hype you up for my next blog post, I’ve figured out how to compile Raylib + Bullet3 for this little handheld device.

Stay tuned!

After switching from an IC role in 25Q2, I’m coming close to my first full year as an engineering manager. Right now, an once-in-a-career opportunity presents itself: I have seen the SWE career ladder from two angles — as an IC and as a manager — and both can be called recent. It’s high time that I write something down, before time etches one away.

At the company I work for, like many mature tech companies, we have a single “software engineering IC career framework.” It’s one big spreadsheet. Rows of skills. Columns of levels. Carefully worded expectations designed to apply to wildly different teams.

It’s also vague by necessity.

Calibrations and promotions, however, are not.

This post is how I bridge that gap for my team.

From a ladder to ledgers

Our framework looks roughly like this:

If you’ve never seen one of these, Dropbox publishes a public version. If you have seen one, you already know the problem: everyone reads the same words and imagines different bars.

To make this actionable, I ask each of my reports to turn the framework into a ledger of evidence. For each engineer, I copy:

• the column for their current level
• the column for the next level

into our 1:1 doc. I add a column after each and ask them to track their work against the expectations.

Think of this as a long-living brag document, but tabulated and explicit.

Each cell needs stories in SBI format (Situation–Behavior–Impact), backed by hyperlinks to artifacts:

• (for technical skills) designs (which, as I explained, can be design docs or roadmaps), pull requests and reviews thereof,
• (for impact skills) launch announcements, write-ups
• (for cultural skills) talks, slides, recordings

For glue work, I even ask my team members to consolidate email threads, Slack conversations, and meeting notes to Google docs, so that they don’t get lost due to data retention policies.

Not because I love paperwork — but because promotions are decided by people who weren’t there. By allowing a stranger to independently verify the claim, artifacts kill “trust me bro” narratives.

How this document is used

I tell each of my reports the same message:

How stories are used:

• Current-level stories feed directly into end-of-year performance calibration.
• Next-level stories become raw material for a promotion packet.

How expectations are evaluated: In each box,

• putting one story is called “show traits” of the corresponding expectation.
• Multiple, evenly-spaced stories are required to say “consistently meeting” it.

Stealing a metaphor from our VP: Dunk a basketball once, you are called lucky; Dunk it repeatedly, you are called MVP. (which is one “M” more than “VP”. Isn’t that nice?)

Off-line, I review new entries they provide. I highlight what perfectly fits the expectation and should be repeated, and I point out what doesn’t align. With a small team, I can afford to repeat this for everybody at least bi-weekly. This made calibration prep incremental instead of a Q4 panic attack.

Promotions?

For those who are not yet at their terminal levels, I also clarify

How you get promoted:

1. Consistently meeting most next-level expectations earns you a promotion packet.
2. A promo packet, plus 7 or more upvotes from senior-than-you colleagues, lands you a trial run in front of the promotion committee.
3. In the committee, a good business justification (“why do we need another person at this level, and why it has to be this person”) and sufficient budget get you promoted.

Miss any one of these, and the answer is “not yet,” regardless of performance.

How we work towards it together:

1. We co-author your promo packet as we go. I happen to be very good at writing.
2. We can ask people for feedback anytime; don’t wait for promo seasons. Request it via Workday yourself, or let me know if you want me to.
3. When the promo season approaches, I write the business justification. If you are a staff engineer, you write it first.

After the committee, we cross our fingers in hope of a sufficient budget.

Why artifacts are often misaligned

When an artifact doesn’t match an expectation, it’s rarely malicious. It usually comes from two forces:

• Generality: The framework is vague by design. It has to apply to many teams doing very different things.
• Eagerness: Most people want to grow. It’s tempting to glorify an otherwise mundane achievement.

My job is to narrow that gap — by annotating expectations with concrete examples and reviewing entries continuously. If something doesn’t align, we fix it early, not at calibration & promotion time.

Surprises are a management failure.

Closing

Career frameworks don’t calibrate or promote people. Evidence does.

My goal as a manager isn’t to relax or tighten the ladder, but to clarify it. I do so such that no one gets surprised by their rating, their promotion outcome, or what “next level” actually means.

If this feels mechanical, good! Career design should be (almost boringly) predictable; The work is hard enough already.

In the next post, I’ll describe how I assign work and create opportunities for my team members to shine, proving themselves capable of each skill the ladder demands.

Disclaimer & appendix. This post used ChatGPT for polishing prose, as well as generating the following appendix of common failure modes:

• Drive-by staff work: One impressive moment mistaken for readiness. Fix: traits ≠ consistency.
• Invisible ownership: Critical systems kept alive with no artifacts. Fix: require durable evidence.
• Manager telepathy: The bar exists only in someone’s head. Fix: annotate, review, repeat.
• Calibration surprise: “Not even close,” revealed at EoY. Fix: if it’s a surprise, management failed.

In software, we use the MoSCoW method to prioritize requirements: must-haves, should-haves, could-haves, and won’t-haves.

Maybe I’m taking it too far, but I’ve been running my kitchen this way.

The Must

When I invite friends for lunch, there has to be a “wow” dish — something worth their time and appetite. It might be a hard-to-find local specialty, a nostalgic favorite that transports them back to childhood, or a recipe that’s been hyped in our group chat for weeks.

It’s the reason they drive 10 miles each way, skip breakfast, and snap a Instagram post.

This centerpiece is usually rich and meaty. Lately, that’s been lamb spine stew (羊蝎子), pressure-cooked ham hocks (大棒骨), or stir-fried clams (炒花蛤). Most can be cooked the night before, giving me a chance to quietly cancel if things go sideways.

So I go bold. I order exotic ingredients, try rare recipes, and improvise proportions. Only when the main dish is off the stove do I think about the rest. It’s either the spotlight or the stoplight.

The Should

There should be one or two veggie-based dishes. Light, clean, and refreshing. They balance out the heavy main and make everyone feel less guilty for indulging. Even the most diet-conscious guest should find it easier going for seconds.

Here, I play it safe: microwave-steamed lettuce with oyster sauce (蚝油生菜), or a smashed cucumber salad (拍黄瓜). They take under 15 minutes, yet they bring freshness and color to the table.

When the main course is drenched in gravy, guests expect to see greens. If I can’t deliver, no excuse will save me — only a bag of frozen broccoli florets might. That’s why these are should-haves.

The Could

Asian meals usually need a carb component.

I’m from China northern, so my carb choice wheaten (skrrrr). If I’ve got time the night before, I’ll knead something from scratch. Flavored flatbreads (椒盐饼, 香河肉饼, 麻酱糖饼, 千层饼, 葱花饼, …) or steamed buns (馒头, 花卷, …) are often a hit.

After the meal, I like sending guests home with a few pieces of my pastry, sealed in a Ziploc bag. (Oh yess… It just has to be a Ziploc, like how mama packed their school lunches back then.) It’s a small, edible souvenir of the day, a reminder — during their future meals — that Ming’s a good cook.

But I never stress over it. It’s a could-have: delightful, but optional. When time runs short, my trusty rice cooker ensures no one leaves hungry.

The Won’t

Then there are the won’ts.

Some friends adore foie gras or fancy pastries, but I’m no trained chef — most delicacies and desserts are out of my reach. Unless I have an unusual amount of time (and perhaps a touch of boredom or a need to flatter), I usually skip their culinary wishlists. I’ll get there one day — just not in this release cycle.

A side note: I confused myself while writing about the won’ts. My first draft went:

I avoid serving bottled soda, canned food, or pre-packaged salads. They dilute the cozy, intentional feel of home cooking. A home meal should taste like time and attention, not convenience. Unless a guest explicitly asks for a refrigerated Coke, the only drinks they’ll get are my home-brewed kvass or kombucha.

But that’s not quite right — in MoSCoW, won’t-haves aren’t anti-goals; they’re features deferred to future versions. The difference matters.

Afterthoughts

In software, we use MoSCoW to decide what must be built now and what could wait.
At home, I use it to remind myself what makes a meal meaningful.

To rehash the analogy:

• Must: The reason they come to your dining room instead of a diner.
• Should: The expected features whose absence would make the l(a)unch a shame.
• Could: The extra delights that extend the pleasant experience. They may even trigger re-engagement.
• Won’t: The desired features we’re not ready to deliver just yet.

Good hosting, like good product management, is about prioritizing — whether you’re feeding a table of friends or shipping a product with limited resources.

§1. Preamble

In recognition of the operational ambiguity, domestic confusion, and occasional hallway disputes arising from inconsistent interpretations of thumbturn orientation on residential door locks, this document hereby establishes the Residential Thumbturn Orientation Standard (hereinafter referred to as “RTOS”) for public reference, voluntary adoption, and ceremonial citation.

This standard is intended to provide a definitive framework for interpreting the rotational position of interior thumbturn mechanisms as they relate to the locked or unlocked status of a residential door. It shall apply to manually operated, non-electronic, single-cylinder deadbolt locks installed on the interior side of residential entry doors.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and
“OPTIONAL” in this document are to be interpreted as described in
RFC 2119.

§2. Definitions

2.1 “Thumbturn” SHALL refer to the rotatable component affixed to the interior side of a door lock, typically operated by hand, and used to extend or retract the locking bolt (also known as the latch or deadbolt).
2.2 “Locked Position” SHALL refer to the state in which the bolt is extended into the strike plate, thereby preventing the door from opening without external key or internal manipulation.
2.3 “Unlocked Position” SHALL refer to the state in which the bolt is retracted, allowing the door to open freely.
2.4 “Horizontal Orientation” SHALL refer to the thumbturn being aligned parallel to the floor plane.
2.5 “Vertical Orientation” SHALL refer to the thumbturn being aligned perpendicular to the floor plane.

§3. Operational Standard

3.1 When the thumbturn is in the Horizontal Orientation, the lock SHALL be interpreted as being in the Locked Position.
3.2 When the thumbturn is in the Vertical Orientation, the lock SHALL be interpreted as being in the Unlocked Position.
3.3 Intermediate or diagonal orientations SHALL be considered indeterminate and subject to local interpretation, user intuition, or direct physical verification.
3.4 In the absence of visual indicators, users are encouraged to gently test the door before assuming its status.

§4. Compliance References

4.1 This standard draws conceptual inspiration from, but does not claim formal alignment with, the following regulatory and industry documents:

• International Building Code (IBC) 2021, §1010.1.9.1
• ANSI/BHMA A156.2–2017: Bored and Preassembled Locks and Latches
• California Building Code, Chapter 11B (Accessibility)

4.2 RTOS SHALL not be construed as a legally binding document, nor SHALL its adoption imply compliance with any jurisdictional building code, insurance requirement, or spiritual doctrine.

§5. Scope of Applicability

5.1 RTOS applies to residential environments, including but not limited to single-family homes, apartments, condominiums, and any dwelling unit where thumbturn locks are present.
5.2 RTOS does not apply to commercial buildings, electronic locking systems, biometric access devices, or doors operated by sentient artificial intelligences.
5.3 RTOS may be ceremonially adopted by households seeking clarity, consistency, or a sense of procedural gravitas.

§6. Ceremonial Adoption and Household Ratification

6.1 Any household, dwelling unit, or semi-organized living arrangement MAY adopt RTOS-001–2025 through one or more of the following mechanisms:

• 6.1.1 Verbal Affirmation: A household member SHALL declare, aloud and with conviction, “Horizontal means locked. Vertical means unlocked. So say we all.”
• 6.1.2 Printed Proclamation: A physical copy of RTOS MAY be affixed near the relevant door, preferably laminated, framed, or otherwise protected from humidity and passive-aggressive editing.
• 6.1.3 Digital Citation: RTOS MAY be linked, bookmarked, or referenced in household group chats, shared drives, or smart home dashboards.
• 6.1.4 Annual Reaffirmation: Households MAY choose to reaffirm RTOS during a designated Lock Awareness Day, ideally coinciding with daylight saving time or other calendrical rituals.
• 6.2 Adoption of RTOS SHALL NOT require notarization, legal counsel, or HOA approval, though such embellishments MAY be pursued for dramatic effect.
• 6.3 In multi-occupant dwellings, unanimous consent is recommended but not required. Dissenting parties MAY submit formal objections via sticky note.

§7. Disclaimer

This document is provided “as-is” without warranty of any kind, express or implied. The authors disclaim all liability for lockouts, break-ins, marital disputes, or existential crises resulting from misinterpretation of thumbturn orientation. Users are advised to exercise common sense, caution, and door-testing behavior.

This document is drafted with assistance from artificial intelligence (AI) technology, as the author is not eloquent in legalese themselves.

§8. Revision and Citation

RTOS-001–2025 is a public draft and may be revised, forked, or parodied at any time. Citation is encouraged, especially in hallway debates, family group chats, or passive-aggressive signage.

That question humbled me when I landed my first job out of college.

How dare we call ourselves “engineers”? To my ears, the term carries a weighty sense of responsibility. When a civil engineer makes a mistake in production, bridges collapse, buildings fall, and lives may be lost. In contrast, a `NullPointerException` on a landing page? Nobody even notices.

My expectation for all (software|civil|electricity) engineers — in contrast to (programmers|construction workers|electricians) — is to design.

Design, as I see it, comes in two forms:

• Architecting. This reflects your understanding of what we want. The key activity is making choices — weighing trade-offs, comparing options, and shaping systems with intention. Your skill here is shown through artifacts like design docs (for us the software engineers) and blueprints (for the civil type).
• Planning. This reflects your understanding of how to get there. The key activity is breaking down objectives — goals into milestones, milestones into tasks. Your skill here is reflected in roadmaps.

Entry-level software engineers are not expected to do either. At least I wasn’t back then, and won’t for my team today.

Your definition may differ, but here are my expectations:

1. An entry-level software engineer can implement with assistance.
2. A less junior software engineer can implement something from start to finish on their own. They start contributing to designs.
3. A terminal-level engineer both implements and designs on their own.
4. A senior engineer codes less but designs more. They also sway designs from teammates.
5. A staff engineer codes even less. They steer designs across teams.
6. A principal engineer doesn’t code or write designs themselves. They oversee designs.

For the first five years of my career, I wanted the industry to be more honest with job titles. I thought we should rename “entry-level software engineers” to software developers or programmers.

But last year, with the rise of AI coding tools, my thinking shifted. Echoing Steve Yegge’s controversial essay The Death of the Junior Developer, a troubling idea emerged: companies may stop hiring for entry-level roles.

And that has consequences for both sides of the job market:

• New grads will have a harder time finding a job — at a time when it’s already tough. With the entry door shutting off, there are less opportunities to grow into proper engineers.
• Companies are headed for a cliff: if no one hires junior engineers today, there will be no senior engineers to run the business tomorrow.

That’s when I began to appreciate the hidden value in keeping the “engineer” title for junior roles.

How static was my view in how job titles were designed! The word is there not because candidates must already be engineers in the purest sense, but because the role invites them to become one. That’s why it’s also called “entry-level” — they’re shown the door in, given a seat at the table. They observe, learn, and grow. And that growth is intentional. The company isn’t just hiring them to write code — they’re investing in someone who might, someday, design.

Contrast this with how many outsourced programmers are treated.

They’re usually handed highly detailed specs written by a full-time employee — someone who does qualify for the “engineer” title in its classical sense. They’re expected to implement the software, sometimes with handholding, sometimes completely independently. But they’re rarely invited to design meetings. They’re rarely offered training or mentorship. They’re hired to deliver output, not to evolve.

This is the key distinction I’ve come to believe in:

“Programmer” and “entry-level engineer” may do similar work, but they are not the same role. The difference lies in the employer’s expectation — and commitment — to help them grow.

So please, hiring managers: keep your junior engineer postings.

Call them engineers — not because they already are, but because you believe they can be. Because you’re willing to grow them into someone who will one day take on responsibility, make hard choices, and design systems that last.

Further reading: Doug Turnbull’s Your Company Needs Junior Devs expands on why investing in juniors benefits more than just your future talent pipeline. It also drives innovation, diversity of thought, and organizational resilience.

In pharmaceuticals, this path is well-charted — beginning with isolated experiments in glass tubes and culminating in trials among living, breathing humans. Each stage offers a different lens on truth, balancing control and complexity, certainty and ambiguity.

Software development, while less bound by regulation, follows a similar arc: from simple unit tests to vast, live user experiments. Understanding this parallel invites us to reconsider how our creations interact with a complex world.

Stages

We can draw the following analogies:

Let’s now break that comparison down stage-by-stage.

Unit Testing → In Vitro (in petri dishes)

The drug is first examined in the quiet isolation of a petri dish. Here, the world is distilled to the barest essentials — a molecule, a receptor, a reaction. Truth is found in controlled conditions, far removed from the noisy complexity of life.

Likewise, unit tests verify the smallest units of code. These are the foundations of trust, where behavior is deterministic and outcomes are certain. But this certainty comes at a cost: such tests tell us little about how parts fit together or respond to real users.

Integration Testing → In Situ (e.g., in cut-off tissues)

Step by step, complexity grows. In situ (“in its original place”) tests observe molecules within their native tissue environment — a place of relationships and constraints. The context matters, though the organism is not yet whole.

In software, integration tests reveal how components cooperate. They catch the frictions and misalignments invisible in isolation, yet still in a semi-controlled setting.

Dogfooding → Animal Testing

From this point on, we go in vivo (“in the living”).

The transition to living systems — animals or cell cultures — brings new challenges. The whole is greater than the sum of its parts; individual characteristics disturb results unpredictably.

Dogfooding invites employees to live with the product. Just like how lab rats aren’t the species that drugs are usually designed for (namely, humans), your colleagues are often not the targeted end users of the feature under test. In terms of improving fidelity, we still have a long way to go.

Alpha Testing → Phase I Trials

The first humans touch the drug, cautiously. Phase I is a study in restraint and observation — small groups, intense monitoring, uncertainty measured carefully. EKG electrodes are wired on. Breathing masks are attached.

A whole medical team stands by, in case of mishaps.

Alpha testing mirrors this. A trusted circle — often loyal users, by invitation — pokes around the software. Eyeballs are tracked. Screens are recorded. Pointer movements are stored.

Bugs here have a controlled blast radius.

Beta Testing → Phase II Trials

The lens widens. Efficacy and side effects begin to reveal themselves when the drug is tested in a broader population.

Beta testing exposes the software to end users who (often spontaneously) opted in. Feedback may be uncomfortable but is indispensable. This is where assumptions meet experience.

A/B Testing → Phase III, Randomized Controlled Trials

Randomized Controlled Trials are the pinnacle of scientific rigor in drug development — isolating cause and effect amid complexity.

A/B testing carries this torch in software. Carefully controlled experiments tease out what truly moves the needle, separating intuition from evidence.

Public Launch → Phase IV, Post-Marketing Surveillance

Approval granted, the drug enters the world, its story far from over. Post-market surveillance seeks the faintest signals of trouble, the rare side effects that eluded trials.

Software launch is no different. Monitoring, observability, and iteration are lifelong companions. The work does not end; it merely begins anew.

Environments

In software engineering, environments such as staging, pre-production, and production represent carefully graduated spaces of exposure — each step closer to the real world, each carrying greater risk and complexity.

These environments map naturally onto the biological testing continuum:

Far from mere formality, these environments represent a philosophical acknowledgment: we cannot skip the journey from known to unknown. They are the quiet guardians of quality, preparing us for the unpredictable realities of production.

Final thoughts

We seek control, yet confront chaos. We demand certainty, yet accept provisional truths. Each test, each trial, is a measured step into the unknown.

Recognizing this can transform how we approach testing. It is not a hurdle, but a discipline. Not a burden, but an inquiry.

The world is never as simple as our tests pretend. Neither code nor cure emerges fully formed.

In embracing the layered, iterative nature of validation — from in vitro simplicity to in vivo complexity — we cultivate not only better products, but wiser practitioners.

May this reflection serve as a quiet invitation: to test with intention, to release with respect, and to build with humility.

My high school ran 15 hours each day. Getting up at 6:30 and to bed at 11PM meant constant sleep deprivation for the teenage me. What kept me going was instant coffee.

Class breaks weren’t enough for a proper brew. Not even a brew, to be exact. I used to chew instant coffee right from the stick-shaped package. It was one of those snacks that you wouldn’t be socially pressured to share.

As stupid as any 15-year-old can be, I once tried to sniff it into my nostrils with a paper-rolled straw, as if I was a drug dealer in a crime film. That one choke kept me off the streets forever.

Later in college, I moved to Waterloo, Canada. Before I could move in to the student housing, I had to stay in a BnB for two nights. My first morning in Canada started at 4AM, thanks to jet lag. Although the host had invited me only to breakfast by 7AM, I got bored and decided to wait in the dining room. Sitting on the table was a jar of brownish liquid.

“I could use a cup of coffee today,” I told myself.

So I poured myself a mug. It was suspiciously viscous, but I blamed it on the northern temperature.

The first mouthful was terribly sweet.

You see, any normal foreigner would have stopped and questioned the liquid right at that point. I was different; I’ve seen this, or so I thought. On my flight from Beijing to Toronto, I had read the brochure about Canadian specialities.

“This must be the famous ‘double-double’ coffee,” the fresh-off-the-boat me thought, continuing with the sips.

It was half an hour — and half a mug — later when the host showed up and greeted me with two questions,

“How was your sleep, and why are you drink maple syrup?”

I should’ve read further.

It impressed me that the 1k-acre campus sported 5 Tim Hortons shops. Joining other culinarily-challenged undergrads there, I solved my breakfast needs at a Tim Hortons every morning. The diet always consisted of a farmer’s wrap or a blueberry muffin, with a medium double-double.

Thus, it shouldn’t surprise you that I consider myself addicted to this particular coffee brand. It was so well-known that, when my friends from the Six visited me in California back in 2023, they brought me half a gallon of ground coffee:

Despite being a software developer, I once had to read a law school textbook from cover to cover. A friend in UK made me do it.

At that time, he had just become a barrister (similar to litigators in the states). I misheard him and thought he said barista.

“Starbucks or Costa?” I asked.

He blinked. “I don’t handle corporate cases.”

Naturally, I took that to mean, I don’t work at chain stores. So I followed up with, “Oh, where do you work then?”

“Chambers at [Generic & Sons LLP].”

“Nice. Lawyers basically live on caffeine, amirite?”

Taking that as a strange turn in topic, he paused, then said, “I don’t actually like coffee.”

This broke me. “Then why become a barista?”

My friend, who must thought that I was philosophizing about the legal profession, responded seriously: “Many barristers don’t drink coffee.”

I nodded thoughtfully. “Ah, like how some bartenders go teetotal.”

The air went still. The silence was so sharp, you could get paper cuts off it.

Then he asked, cautiously, “What do you think barrister means?”

“…Someone who makes coffee?”

He closed his eyes in agony. “That’s barista. I’m a barrister. A lawyer.”

Cue the longest pause in the history of our friendship.

“Sooooo… wanna learn how to pour a heart?”

If there’s one entry that I’d wish the Devil’s Dictionary had included, it would be this:

Programmer (noun): A machine that turns coffee into code.

Indeed, I can’t start my day without a cup of Joe. Over the past 5 years, I have brewed 16 kg of coffee at home alone. That is excluding brews I had at work and coffee shop adventures. Over time, I’ve tried so many types of coffee beans that I have started an album of their packaging:

During those stay-at-home years, I came to learn about and admire digital nomads; a certain Marius in particular, who keeps record of all the coffee beans they’d tried around the world:

That clicked with me. I want to keep a table like that. I wanted to do it so badly that I paid for Notion just to try out their “publish a database to the web” offering. But embarrassment strapped me:

• I’m a lousy barista, paying no attention to the technique, timing, or temperature at all. I guess I got it from my Asian lineage: In the kitchen, we always measure “by the feel” (c.f.). I can never be like James Hoffmann.
• I can’t taste the premium. My tongue tells no difference between artisan roasters and Starbucks. As my purchase history revails, I generally grab whatever grabs my eyes from the shelf of my local corner store.
• I can’t smell the aroma. Maybe that sniff back in high school really did something to me.

So I never did. I didn’t even dare to write a blog post about coffee.

That is until I read the essay, The Case for Bad Coffee, by Keith Pandolfi. The gist: it’s not about coffee, but rather the occasion when you had it.

To Keith, the best coffee was the sip his father left at the breakfast table when he was 9 years old. The best coffee was from a foam cup when he saw his father becoming sober at 14. The best coffee was with his high school friends before applying for universities and without them after getting accepted to a different college.

I’m getting it. Perhaps my best coffee was a Nescafé 3-in-1 I chucked down my throat back in high school. Or it may be a CA$2 Tim Hortons that I rolled up and won nothing. Then it may be actually a mug of syrup. Heck, it might not even been here just yet; someday, a certain English lawyer may treat me to a hand-made latte.