Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
- Hello. Hi, my name is Michel Martens. I'm from Argentina. I've been using Ruby since 2003. At that time there were no big Ruby areas like like Rails or RSpec or Bundler. As far as I can remember, at that time, it was all about small libraries that highlighted how expressive Ruby is.
And I think that created a big impact in me because I tried to always create small tools that sold very specific products with little code. My username on Twitter, at soveran. Most of the code I write is open source and it's in my GitHub account. I have a company called openredis, which provides redis sourcing.
Redis is an in-memory database. This presentation is about human error and how it relates to the concept of Mental Models and Simplicity. I guess we are all familiar with human error. We make errors all the time. When we are developing, when we are programming we can hit the wrong key or maybe we can forget a comma or write the wrong algorithm.
And it's a very forgiving environment because we have plenty of time. There are no big consequences. Consequences. We have the help of our text aid or our interpreter compiler, or whatever. So, we can, in the worst case, just run the program, see if it works.
But something completely different happens when we are dealing with an issue in production and our website is down and we have an emergency. And a few years ago I realized that I had never trained for that kind of situation, dealing with an emergency. We are usually racing against time.
Every error we make. . . Yeah? - [Man] I'm sorry, could you speak up? And just refer to the mic. Maybe move to the mic or something. Yeah it's a little. . . - Hello? Hi. Yeah, doesn't work? Hi. - [Man] Oh, much better, yeah. - It was upside down. That's a technical error.
But we will learn that behind all human error, there's a design error, so. My jacket was badly designed. - [Man] Maybe in your shirt? - Okay. - [Man] Sorry. - Voila. Okay, way better. I was talking about human error in general. So, yeah. I was talking about this idea that we make errors in development and there's no big deal because we are not under pressure.
But when we are dealing with an error in production and, maybe, our customers are complaining, and every error we make can be critical. What happen to me was that I realized, at some point, that I had never read anything about dealing with those kinds of emergencies.
So, I started investigating. I read a lot about accidents in aviation and power plants. It's fascinating, it's addictive. I discovered a lot of things about dealing with crisis. Especially, this one thing called crew resource management. I think there will be a presentation tomorrow, at the same time, about that topic.
In everything I read, there was always a reference to this book called Human Error by James Reason. He did a lot research in that area and historical research and, also, he proposed a model to classify human errors based on our behavior. He, also, proposes some ways of preventing whole types of errors and things like that.
It's very academic, he makes a lot of refer. . . It's like a paper but with 300 pages. But if you are in to the topic, it's very interesting. Another book that was very interesting for me was The Design of Everyday Things. The Author, Don Norman, he's a psychologist, but he's, also, an engineer.
A lot of things that he says applied directly to what we do to the things that we build. And the main idea of that book is that behind every human error there's a design error. Because we are expert at making mistakes, it's our thing. A good design should account for that fact.
Should prevent us from making silly mistakes and should help us detect the error and recover from the error. I really recommend that book. I can't cover everything that there is in those books, but I really recommend that you read them. And I want to focus on something that is very related to this track of let's code.
And this has to do with building accurate Mental Models of the systems we are building or using. A Mental Model is the presentation we have of a system. And it has to do with how a system works, its internal design. First thing to clarify is that it's not the same to know how to use something or knowing how it works.
In order to know how it works, if we are talking about software, it means that we need read the code and understand what it does. If we do that and we create an actual mental model, we will be less likely to use it in the wrong way. And, also, when something goes wrong, we can instantly know where to look for the problem.
[ ... ]
Nota: se han omitido las otras 2.268 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.