Lisa Karlin Curtis

Biography

Full Stack developer at GoCardless - started out as a consultant working with HMRC and then smart meters, before accidentally becoming a developer. I mainly work on our main Rails app, with some forays into our JS front end and a legacy PHP application. I love building stuff, but am also interested in how people interact with each other in a work environment - particularly in software engineering. I’m a massive nerd (unusual in these parts, I know), but I also enjoy cooking and pretty much any competitive sport (well, the British ones anyway).

Talk description

Breaking changes are sad. We’ve all been there; someone else changes their API in a way you weren’t expecting, and now you have a live-ops incident you need to fix urgently to get your software working again. Of course, many of us are on the other side too: we build APIs that other people’s software relies on. There are many strategies to mitigate breaking changes: think SemVer or API versioning, but all rely on the API developer identifying which changes are breaking.

That’s the bit we’ll focus on in this talk: how do you (a) Get really good at identifying what changes might break someone’s integration (b) Help your API consumers to build integrations that are resilient to these kinds of changes (c) Release potentially breaking changes as safely as possible.