So, how do you inspire or ensure that the Einstein level of simplification is reached? So, can you do code review? Can you look at code? If I gave you the code for the Ford F-150 and said, "Here, is this a mess or is this okay?" Is it possible to tell?

Is it possible to regulate? An experienced developer can look at code and see if it smells. Mixed metaphors deliberately. The point is that it is hard to generate something that is really obviously clean and can be appreciated. But you can usually recognize when you haven't reached that point. And so, I've never looked at the F-150 code, so I wouldn't know.

But I know what I ought to be looking for. I'll be looking for some tricks that correlate with bugs and elsewhere. I have tried to formulate rules for what good code looks like. And the current version of that is called the C++ core guidelines. One thing people should remember is there's what you can do in a language and what you should do.

In a language, you have lots of things that is necessary in some context, but not in others. There's things that exist just because there's 30-year-old code out there and you can't get rid of it. But you can't have rules that says, "When you create it, try and follow these rules." This does not create good programs by themselves, but it limits the damage for mistakes.

It limits the possibilities of mistakes. And basically, we are trying to say, "What is it that a good programmer does?" At the fairly simple level of where you use the language and how you use it. Now, I can put all the rules for chiseling and marble. It doesn't mean that somebody who follows all of those rules can do a masterpiece by Michelangelo.

That is, there's something else to write a good program, just as there's something else to create an important work of art. That is, there's some kind of inspiration, understanding, gift. But we can approach the sort of technical, the craftsmanship level of it. The famous painters, the famous sculptors was among other things, superb craftsmen.

They could express their ideas using their tools very well. And so, these days, I think what I'm doing, what a lot of people are doing, we are still trying to figure out how it is to use our tools very well. For a really good piece of code, you need a spark of inspiration.

And you can't, I think, regulate that. You cannot say that, "I'll take a picture only, I'll buy your picture only if you're at least Van Gogh." There are other things you can regulate, but not the inspiration. I think that's quite beautifully put. It is true that there is, as an experienced programmer, when you see code that's inspired, that's like Michelangelo, you know it when you see it.

And the opposite of that is code that is messy, code that smells, you know when you see it. And I'm not sure you can describe it in words, except vaguely through guidelines and so on. Yes, it's easier to recognize ugly than to recognize beauty in code. And for the reason is that sometimes beauty comes from something that's innovative and unusual.

And you have to sometimes think reasonably hard to appreciate that. On the other hand, the messes have things in common. Yes. Yes. Yes. you you you you you you you