We can make software engineering far less painful than it is right now. This is the main lesson Yoz Grahame has learned in 25 years of coding, consultancy and troubleshooting. It’s why he became a Developer Advocate for LaunchDarkly: to give people better tools to create better products.
The previous involvements that got him here include: the US Government (in the 18F group), Compaas, Linden Lab (Second Life), Ning, British e-democracy projects WriteToThem and TheyWorkForYou, and Douglas Adams’s startup The Digital Village. He’s previously spoken at such conferences as O’Reilly’s Emerging Technology Conference, OSCON, LISA, and Open Source Bridge. On the amateur wrestling circuit, he’s known as “Dr Henry Metzger”.
How often do you write code that works first time? How often does it happen when trying a new framework or SDK? And how often will it to happen to developers trying out your product?
The chances are that most people attempting to code with your SDK will hit at least one error message. Probably several. When they hit those errors, you’re not going to be there to help them. All you can give them is the message they see. When they see that message, will they keep trying, or give up?
Here’s the good news: you can make your errors even more helpful to new developers than having you sitting next to them.
There is such a thing as a beautiful error message, and when you see one, you’ll agree with me. (Probably.) And then you’ll want to make your errors look like that, and I’ll show you how. And then you’ll get excited about how much better your developer experience will be. It’ll be great.
Some of the topics I’ll cover:
* Ways in which error messages can make things worse
* Treating your errors like documentation
* Extracting useful context, and using it to provide help
* The most useful times and places to show errors
* Metrics and feedback – which errors are your users actually hitting? What fixes should your team prioritise?