Speaker

The A/B test! We've all thought it: "What's the point? How much configuration do we need?" If you're familiar with the scientific method, those steps carve out the path to experimentation and A/B testing. Everyone loves a good hypothesis right? I know I do. Melding the world of science and software can help alleviate the stresses of experiments and help to maximize impact of every feature. In this talk we will journey through what an A/B test is, defining goals for A/B testing your app, and rolling out features based on successful experiments.

Is your app behaving strangely? Random network calls? Unexpected behavior? It might not be a bug, it might be possessed. In this spooky session, we’ll explore how malicious packages sneak into your codebase like ghosts through an open portal. You’ll learn how typo-squatting, dependency confusion, and supply chain attacks haunt the JavaScript ecosystem, and how to perform a proper exorcism. We’ll go beyond npm audit and explore tools and habits to stop the haunt before it begins. Leave this talk with a toolkit that wards off evil; digital and otherwise.

In an industry obsessed with speed, scale, and constant reinvention, we rarely stop to ask whether the way we build software is healthy, for our users or for ourselves.

Yet hidden in one of the most overlooked engineering disciplines lies a blueprint for calmer systems and more resilient developers.

We often treat accessibility as a grueling “last‑mile” chore, but what if it’s actually one of the best tools we have to survive this profession?

This talk explores a Developer’s Paradox: the idea that by slowing down to build for users with visible and hidden impairments, we inadvertently create technology that’s more predictable, maintainable, and humane and in doing so, we reduce our own risk of burnout.

By trading chaotic, over‑engineered complexity for intentional, calm technology, we don’t just make better interfaces.

We reduce cognitive load, simplify our architecture, and build codebases that work with us, not against us.

Accessibility principles push us toward clarity, consistency, and resilience — qualities that benefit every engineer, every codebase, and every team.

This keynote is an invitation to reframe accessibility not as a constraint, but as a path to more sustainable engineering. When we build for the edges, we strengthen the center, including ourselves.

In an industry obsessed with speed, scale, and constant reinvention, we rarely stop to ask whether the way we build software is healthy, for our users or for ourselves.

Yet hidden in one of the most overlooked engineering disciplines lies a blueprint for calmer systems and more resilient developers.

We often treat accessibility as a grueling “last‑mile” chore, but what if it’s actually one of the best tools we have to survive this profession?

This talk explores a Developer’s Paradox: the idea that by slowing down to build for users with visible and hidden impairments, we inadvertently create technology that’s more predictable, maintainable, and humane and in doing so, we reduce our own risk of burnout.

By trading chaotic, over‑engineered complexity for intentional, calm technology, we don’t just make better interfaces.

We reduce cognitive load, simplify our architecture, and build codebases that work with us, not against us.

Accessibility principles push us toward clarity, consistency, and resilience — qualities that benefit every engineer, every codebase, and every team.

This keynote is an invitation to reframe accessibility not as a constraint, but as a path to more sustainable engineering. When we build for the edges, we strengthen the center, including ourselves.