 Thank you. Good afternoon everyone. We are talking about something irrational, the way that we choose technology. Sometimes the way we choose or we don't choose technology is not rational. And especially we are talking about the unknown, something that scares us, something that we are not comfortable with, something that we don't want to admit to ourselves that is scary. So one thing from somebody who, better than me, can talk about this, Emmanuel Rosen, the author of the Anatomy of Buzz, says that most of the criticism comes from people who don't know what they're talking about. And let's see. Most of the time we say, I couldn't do something like that. It doesn't work because the database, the regular explanation, or the XML, or whatever, didn't work. You must be familiar with this. And I'm going to tell you how this thing works with a few stories. So the first story about who cannot, don't, or want is about Mozart. You know that Mozart sucks, do you? Or maybe not. Anyway, if it does or does not, it's for the same reason that Perl or PHP, MySQL, databases, languages suck. So let's see. First of all, the rumor. Whenever you have a new thing, there will be somebody who'll tell you something good, something bad about that. So it starts this way. You know the emperor at the time of Mozart was the most important critic in the empire. He didn't know anything about music, by the way, but since he was the emperor, he was quite important one. And so one day, while making breakfast in front of all the dignitaries, he asks, how good is it, this Mozart? And whenever you ask something like that, somebody will tell you, he's a remarkable majesty. I heard an extraordinary opera of his last month. So there must be somebody who has done some research and provides some information. So the opera was a domino kind of great, and immediately there is somebody else who didn't like it. So he said that it was a tiresome piece and then we have some flame here, tiresome. Yes, a young man trying to impress beyond his abilities, too much spice, too many notes. Okay, so far the emperor says, okay, let's hear this Mozart, but he has the inner conviction. So he knows that something is wrong with this Mozart. And when finally the concert ends and he's satisfied, he starts by giving some positive feedback to the author. So he says, a good effort, extraordinary, very good. And Mozart is pleased in the beginning, hearing these things, it's new. So Mozart asks, did you like it? And suddenly the emperor converts the feedback into a bug report. He says, yeah, it was very good, but now and then, just now and then was, how can I know, a touch of, and then Mozart starts to panic. How do you, what do you mean? And the emperor tries to find a repeatable bug report and ask somebody for suggestions. How would you once say, director, you remember that guy who didn't like the Mozart in the first place. So the director says too many notes and remember, the rumor comes back exactly. And he says, like it was his idea, that there were too many notes. Mozart, of course, you know, when you find a bug report, the support guys will not agree with you immediately, we'll have to argue back and down. And finally the emperor starts doing some documentation of his bug by asking impossible things to the CTO. And the CTO says, of course, Majesty, you are right. And in the end, Mozart has to downgrade the bug report to a feature request. So the emperor says, just cut to a few notes and it will be perfect. And Mozart says, which few notes did you have in mind? Okay, but this is the story. Does it sound familiar? Now, let's try the same story with a different set. How good is it, this pearl? And, of course, somebody who has seen it, remarkable Majesty, I saw a most extraordinary web service created by Pearl. Gearman distributed service. And immediately somebody says, oh, a right-only type of language, I know it, right only, most complicated language, undistinguishable from line noise. Too much compact, too many punctuation signs. Or maybe you have seen this one. How good is this my SQL? Yeah, you know, this guy knows everything. So it's remarkable Majesty, a friend of mine has a very popular website powered by my SQL. Facebook, a social network, that, a toy database, I seen that too. A toy, you know the flame. A miserable file system with SQL trying to impress beyond the skills. Not transactions. No, not a mission critical database. So you can do it more Java, Linux, Python, Windows 7, and you will find somebody who doesn't agree on that. So too many distribution, too many white spaces, too much hidden DRM. Maybe it's right, but maybe not. And so, let me tell you another story. When I was 13 years old, my French professor told me that you can't learn English. There are too many consonants that can be pronounced by somebody in the south of Europe. Now, you may agree that although I have a horrible Italian accent, I am speaking something that sounds like English. So this was 20 years later that finally I recognized that my French professor, not only he didn't speak English, he didn't even speak French. So I realized that maybe his advice was not sound. So I decided to learn English and I found out that the problem is not too many consonants, it's too many vowels. But this is a different story. Or, you know, I'm Italian, so for me the only coffee that is worth mentioning is espresso. American coffee was an abomination that was advised not to touch at all. But, you know, if you go to American and you find somebody who makes good coffee, it's quite good. Or when back in the 80s they told me that a Mac is something that should not be used by real geeks because icons are for sissies. Now if you see here, you have a Mac. So after a while I realized that that was not a good example as well. Perl is not noise. For many years they told me this and I was using C for system administration. It was really stupid. Finally I tried it and it worked. So you have seen, you have heard stories like that databases don't work or you don't need databases. Spreadsheet is what you need. Database are just a few PHP lines or you should not use VI because it sucks or Emacs because it sucks or MySQL because it sucks or PostgreSQL because it sucks enough. Sometimes the problem is near to you. Sometimes the problem exists between keyboard and chair. So it happened to me many times. You have seen that. Once upon a time I didn't make any mistakes. Then I grew up and I found them. So what happens when you have a complex program? You have a complex program full of many components. These components could be JavaScript, Ajax, CSS, PHP and so on. So what happened? You have an error in your complex application. What do you do? Now the rule of complex application says that you always blame what you don't understand. So you are an HTML expert. Then you can blame Ajax, PHP, SQL. Are you a PHP expert? Everything else can be blamed. SQL expert, PHP is the fault of course. Or if you want more things to blame, you can blame the operating system. You can blame XML processing library. The regular expressions, this is a favorite of mine or actually of many people. You can blame the language. You can blame the weather, especially in Belgium. You can blame abduction by aliens. And if you are Italian, you have a special thing to blame. You can blame your prime minister Gaffes. So there is the first rule of programming, which is you can find in this URL. And the first rule says that it's always your fault. Now, the second rule says there is no second rule. As an example, you have a problem in your application and you blame what you don't understand. For instance, let's blame my SQL. Then you keep looking for non-existent SQL bugs. Actually you file a bug and you scream at the support people. And of course you fail to look at the real cause that was in your code. And you waste hours, days, maybe weeks and months not to find the real error. So remember, it's always your fault. But okay, this is the problem. So what can you do? First of all, you need to be curious. And then you need to be brave. So once you understand that you are at fault, you need to do something. So curiosity is what takes you to the next step. Curiosity is the foundation of innovation. There is no science or technology without curiosity. What else? You need bravery. Because being curious is not enough. You really need to try it on your own. Really. You must go in front of the bull, take the bull by the horns and do something. So how do we assess the problem? First of all, don't blame anything else. Assume that you are wrong. And then the error is going to be easier to find. So the things that you should do is find your weakness and get curious about this weakness. You can explore it a little bit more and find some things about that. Learn how to exploit this weakness and make it into a strength. And then finally, you can fix the problem. So once you are facing the unknown, this is pretty scary. The unknown scares everybody. So don't assume that you can't deal with that. Sometimes the unknown is less frightening than you thought. So this is a duck. It looked like a dinosaur. Yeah, that is a duck. So that's it. I shared with you some personal experience and I hope you will find some good thoughts for improving your own career. Thanks.