00:00:11.540
Hello everyone! Good to see you all.
00:00:15.020
I want to see if I have any humans in the audience. Please raise your hands!
00:00:21.650
Look around at the people who didn’t raise their hands. We might have a few aliens in the room. I'm an alien too; I come from a planet called Mama.
00:00:27.140
Though I spend a lot of my time in Florida for reasons that make absolutely no sense to anyone except me. My alien name is something quite complex; it's hard to pronounce for most English speakers, especially non-French speakers.
00:00:38.989
So, I've put together a little guide for how to pronounce it: You say 'Oh' like in 'oh,' then 'Li' like Bruce Lee, followed by 'V'—not much like anything else—and then 'Yeh' at the end. You're happy, and just remember you're in Paris. It's great here! I can enjoy being a bit tipsy because it's amazing and cheap.
00:01:09.920
This is the name I go by on the internet, and my mom likes it too. That’s why I don’t go by Oliver, even though that might make it easier for ordering coffee in the U.S.
00:01:24.290
For the past six years, I've been developing, maintaining, upgrading, and securing Code School, which is where we created Rails for Zombies, if you know what that is. It was a version of Try Ruby with the Y, featuring the Lucky Stiff cartoons and Chunky Bacon.
00:01:30.200
Sadly, as of June 1st, just 28 days ago, Code School has gone away forever. Some of the great things we built over the years will be living on in a different form on the Pluralsight website, which required a lot of hard work from many of the good people at Code School to revive that same interactive technology learning experience for those who loved it. But still, it's sad to see it go.
00:02:11.690
Today, I want to talk about the mistakes we made at Code School—specifically, the mistakes I personally made over the years. It can be hard to admit those mistakes, and it's often even harder to understand how they happened. Why did it occur? How did it occur? Why are you so sad, especially without any feedback?
00:02:26.240
I liken the process of making mistakes to standing at the bottom of a tall mountain. When you make an error, recovery seems far away and difficult to reach. You could try to climb that mountain, but it would be hard. With feedback, it gets a little easier to navigate your way back to recovery, but it’s still not perfect.
00:02:47.960
If you add context to the equation, it becomes a lot easier to get back to recovery. Having proper context along with good feedback is essential.
00:03:14.590
One issue is that in our field, we work with computers that are often displeased with us. They constantly scream at us with error codes, and we usually react by asking, 'Why us?' Yet, despite the fact that we engage with computers daily, we still tend to get frustrated with users when they stray away from the happy path.
00:03:35.030
One of the most interesting questions to ask when something goes wrong in software development is not 'Why?' but rather 'What?', 'How?', 'When?', and 'Where?'. By backing up and understanding that these questions are crucial, we can start to assess errors more effectively.
00:04:01.230
So, first of all, what is an error? An error has multiple definitions, ranging from spelling errors to errors in judgment or conduct. In technical terms, a technical error measures the estimated difference between observed values and true values.
00:04:21.510
I enjoy etymology, as I used to study linguistics. The word 'error' comes from the Middle English 'error', which in turn comes from the Latin 'error'—which means 'wandering about'. I find that delightful. When we think of errors this way, they seem less hostile. Errors don’t necessarily need to feel like a failure; they can represent a wandering path.
00:04:49.640
However, in programming, the term 'error' has become synonymous with something that feels bad, like a failing build. We aim to stop making mistakes, but of course, it's impossible to eliminate errors completely.
00:05:12.050
When we work on behalf of users—often called end users, which is unfortunate since it implies we want to 'end' them—we are essentially the middle users. We stand between the machines and the end users. Our role is to translate and buffer between the two.
00:06:03.620
However, end users often rush through applications clicking buttons too quickly nonchalantly. They lack the understanding that errors can emerge when they do this. Calling attention to feedback that computers give can be harsh, and sometimes those who build software forget the human element involved.
00:06:25.290
We often blame end users when there are problems, but they do not understand the complexities behind the software. It’s our responsibility to ensure that error messages and feedback are appropriate and easy to understand.
00:06:52.100
When a system throws incomprehensible error messages, it overwhelms the users, and they feel helpless. The end user is merely reacting to what's being thrown at them, just like they run across a busy street without looking.
00:07:17.750
When we get these errors, we need to intervene and offer assistance. This is especially paramount when users confront confusing error feedback. The challenge lies not simply in handling errors but in creating a path toward better understanding.
00:07:50.330
Now, what causes confusion in the user experience? Issues with poorly designed interfaces frustrate users. For example, with credit card chip readers that malfunction for no apparent reason even when input is correct, users may not understand what they did wrong.
00:08:36.400
Also, encountering programming languages where extensions or tools throw errors without clear explanations can aggravate programmers, leading to their confusion. I’ve had such experiences myself.
00:08:53.100
Let me share a short story. A few years back, I started noticing strange exceptions popping up in my codebase related to a method called 'explode'. This method accepted a single code argument. If you attempted to invoke it without an argument, you would receive an argument error indicating that the wrong number of arguments was given.
00:09:58.210
Backtrace messages often help clarify the line of code where the error occurred. If you checked the first line of the code, it would clearly call for an argument. Now, suppose we refactor this method to make its interface clearer.
00:10:24.030
Playing with keyword arguments can also introduce new errors. Let’s say we transition from a regular argument to a required keyword argument. If you attempt to call the method without the proper keyword, an error will arise indicating that the required keyword argument was not provided. This requires careful handling to ensure smooth user experience.
00:11:21.570
These kinds of adjustments can lead to instances where users might unknowingly provide the wrong kind of argument, leading to unexpected behaviors.
00:12:07.230
The important thing is to assess why these errors happen and how we can improve the experience. In situations where the methods produce errors that are obscure or misleading, we have the responsibility to refine the feedback so that users can quickly understand what went wrong.
00:12:40.890
Many programming languages have been evolving their approach to error handling, such as the inclusion of suggestions for fixing potential issues, or user-friendly prompts that guide through the recovery process.
00:13:07.880
Take, for example, some of the innovations seen in modern programming languages. Improved error messages and context clues are becoming a standard for ensuring the users can recover from errors quickly.
00:13:29.090
In Ruby 2.3, a great improvement was made by the inclusion of the 'Did you mean' suggestion feature, which reduces the frustration caused by typographical errors in code. Such user-centric improvements ultimately save valuable time and provide clarity.
00:14:01.630
In programming, we should always aim to facilitate quick recovery from mistakes. The responses given to errors matter a great deal, not only for the immediate interaction but also for the user's long-term experience.
00:14:15.620
Another example comes from Rust, which leads the way in providing excellent error feedback by indicating exactly where the mistake is. Or consider Elixir, which offers detailed compile-time error prompts that give concrete guidance.
00:15:07.900
Programmers must recognize that when errors occur, context is everything. Understanding how things went wrong and providing useful feedback allows users to learn and grow.
00:16:05.040
We can improve the learning experience for others by crafting our error messages thoughtfully. The better the feedback, the more capable our users become at navigating their projects.
00:16:29.500
In closing, improving how we manage errors and providing informative feedback isn't just a nice touch; it's a central part of the developer experience. By taking the time to refine our error handling, we take a step closer to nurturing a more confident and capable community.
00:17:22.370
Thank you all very much for listening! I'm happy to take any questions.
