Software
Should
Work

For concurrent and distributed systems, formal modeling languages like TLA+, P, and Quint are the gold standard for finding bugs before they appear in production. However, our field continues to evolve and now Go and Rust both have checkers that promise to provide “fearless concurrency” by validating your source code directly. How powerful are these checkers? A TLA+ user takes them for a spin.

Container image builds are still based on an idea from 2013: a linear sequence of filesystem snapshots. The Dockerfile was a brilliant abstraction when containers were new, but it imposes constraints that make modern builds slower, less incremental, and harder to parallelize than they need to be.

In this lightning talk, I'll propose a different approach: treating image construction as a dependency graph instead of a sequence of layers. Rather than executing a Dockerfile from top to bottom, we can build container images directly from content-addressed tasks, allowing work to be cached, reused, and parallelized at a much finer granularity.

The result is the same OCI-compatible image, but produced in a way that more closely resembles how modern build systems compile software.

We'll explore why Docker image builds invalidate more work than necessary, why layer-based caching has fundamental limitations, and what a graph-native image build system could look like instead.

If you've ever wondered why a one-line change can trigger minutes of rebuilding, this talk is for you.

Our React tests do not stub out the backend. They do not use MSW. They do not record HTTP fixtures. They run against an in-memory instantiation of the actual server, in the same process as the React tree.

The client and server talk to each other through a TypeScript interface. In production, the React app receives an implementation of that interface that is an HTTP client which makes XHRs to the real server. In tests, that implementation is the server itself, constructed in-process and backed by a real (in-memory) SQLite database created by running our production migrations and seeded using the same helpers we use in our server-side tests. Because the interface is a TypeScript type, every call across the client/server boundary is type-checked at compile time, in production and in tests alike.

Drop the HTTP layer and the tests turn into ordinary function calls. What you give up: a thin smoke test of the HTTP boundary, and the option of writing your backend in something other than TypeScript. What you get back: full-stack tests that parallelize arbitrarily, because each one runs against its own in-memory SQLite database and shares no state with any other. There is no lifecycle to juggle across multiple stateful processes. The same setup utilities work in server-side tests and frontend tests. And there is no mocked or stubbed backend to keep in sync with the real implementation, because there is no mocked backend. I will show one test and trace it from React render to SQLite and back.

Most AI applications have moved beyond chat interfaces and now rely on structured outputs, function calling, and agent workflows. While these approaches work well initially, they often become difficult to scale as prompts grow, workflows become more complex, and reliability requirements increase.

In this talk, I'll share lessons learned building AI-powered developer tools and explain why we started replacing ad-hoc schemas and function calls with purpose-built domain-specific languages (DSLs). I'll show how DSLs can make AI systems more reliable, easier to validate, cheaper to run, and easier for both humans and models to reason about.

We'll look at concrete examples of where structured outputs break down, how a DSL can encode intent more effectively, and practical guidelines for deciding when a custom language is worth the investment.

Accessibility is commonly bolted on instead of thought through at the beginning. This reduces usability for many users. This is a case study of that story for screen magnifiers.

The current state of screen magnifiers is subpar and will essentially never change. Each pixel gets magnified and looks blurry at 5x+ zoom. The (seemingly) reasonable choice of representing the screen as a grid of pixels has unintended consequences.

I'll walk you through my story of how I ran into this, tried to solve it, and ultimately found that it's not worth solving.

It is a hard problem to think of all possible ways software could be used. In the case of screen magnifiers, they will always be a bit blurry. Here, the root solution is designing software in a way that a screen magnifier isn't even needed in the first place.

Visibility into how others use software can help to make sure it is usable for more people. The earlier we know about what those problems are, the better we can make it.

Temporal is an open source platform used by thousands of companies to make applications more reliable. One of its key features is Durable Execution: crash-proof execution that gives applications automatic state persistence and the ability to run reliably for any length of time. In this lightning talk, you’ll see what happens when a Temporal application crashes, and how it automatically recovers and resumes without losing state or unnecessarily repeating work that has already completed.

We have two systems at $work that are getting more loaded over time and started to fall over handling queries from clients.

Counterintuitively, when we improved throughput and latency the systems started suffering from worse performance problems.

In the lightning talk, I’ll explore why this can happen, how to spot accidental load-shedding in a service, and what to watch out for when trying to make sense of misleading metrics.