 Okay, so why are we here this week doing running training sessions? So you've got to look at the big picture. In our industry, software industry in general, you have programmers hacking code, writing tests, delivering things. And then you have R&D, you've got people writing like cryptographers, for example, with cryptocurrencies, and other kinds of, in a way, rather esoteric mathematics and science. And the problem, one of the problems we have in our industry is that, you know, the academic research and the hacking on the code, these kind of are completely different cultures and they live in different silos and the two groups don't understand each other and they don't talk to each other. That's kind of like the industry-wide default. Sometimes in most companies you don't even have any researchers anyway. And so it's very easy to see why there's this huge, huge gulf. But even if you look at large companies like Microsoft, they introduced an entire division, an entire Microsoft research, to try and bridge that gap between academia, all the great ideas are coming out of academia and they're armies of .NET developers or whatever. And so on a much smaller scale, obviously IOHK is a lot smaller than the company like Microsoft, but the same problem exists and you need to find a solution of how do you smoothly get the great ideas and research into development. So what we've done is, I guess, on the lines of Microsoft research, we have a small, but on a smaller scale, a team that sits in between the researchers and the engineers. And that's great, but that's not enough, right, because ultimately you're trying to get the communication going and having translators in between is a good step, but you need to go one more. And in particular, you need to get the people over here to understand this stuff in the middle and the people over here to understand this stuff in the middle. So what we're doing this week is we are working with our engineers and going over lots of material on how to understand some of the stuff in the middle, which is all about mathematical specifications. So in this context, it's how do we go from these intermediate specifications through to how do we understand them, what do they mean, how do we think about them, and then how do we relate them to code and go from there into code or into executable specifications and then into working programs, tests, et cetera. And actually, we need to do somewhat the same thing with the researchers. The researchers or the cryptographers and other people, they use their own notation, their own language for describing what they do. And we need to meet each other halfway. And so this week is about helping the engineers to meet halfway. And to some extent, we're going to have to do a similar exercise with teaching other people of, here's this notation that we use. Can you understand it? Can we all agree on something in between so that we can really have everybody understand the same thing, like what is the specification of the next version of Ouroboros or things like that. So one of the nice things this week has been that the engineers really want to understand all of this esoteric mathematical nonsense. There's a sort of stereotype in this industry that programmers, engineers, they just want to write code and they don't understand all this nonsense. But that's not really true. A lot of people really want to get into the more abstract mathematical ways of thinking about what they're doing. And so that's been actually very nice this week to get that kind of feedback and see that people really want to do this stuff. It's also been nice. We have John Hughes here teaching the team about QuickCheck, which is great because he was one of the people that invented QuickCheck and he's been running a company for years doing that in practice. So it's great to get that kind of stuff from real experts. And other colleagues of mine are here as well helping to run the teaching based on years of experience of teaching to students and to industry professionals. So it's been nice.