#253 Mathias Verraes from music to languages and models

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Mathias Verraes 0:00
That's what I mean by getting that language and looking for that, that subtlety somewhere that nuance and trying to pinpoint it and taking it and labeling it and putting it on the whiteboard and having discussions and turning it into, you're making the part of the artifact. And now you have something that is at a higher abstraction level, right? We don't have to say a claim came in from that source with these parameters, etc, we can say, a claim with trust five, from a source which was like much higher level or this set of rules, this the FUBAR strategy and the FUBAR strategy needs to have this rule from the bus strategy. Something like that. Right. You, you, you reason about is much higher order building blocks, you become more efficient, it's more understandable, but you start seeing opportunities for doing things that you couldn't even think of before. that I find extremely fascinating. That's That's why I why I do this job.

Tim Bourguignon 1:04
Hello, and welcome to developer's journey, the podcast, bringing you the making of stories of successful software developers, to help you on your upcoming journey. I'm your host Tim Bourguignon. On this episode, I receive Mathias Verraes. Mathias founded Aardling, a software modeling & design consultancy with a penchant for complex environments. He focuses on design strategy and messaging-centric domain modeling. Mathias has been speaking at various conferences since 2011 and is the founder of the DDD Europe conference. And finally, when he’s at home, he enjoys helping his two sons build crazy Lego contraptions! Mathias, a warm welcome to DevJourney.

Mathias Verraes 1:57
Thank you, Tim for having me on.

Tim Bourguignon 2:00
It's my pleasure. But before we come to your story, I want to thank the terrific listeners who support the show every month, you are keeping the DevJourney lights up. If you would like to join this fine crew, and help me spend more time on finding phenomenal guests then editing audio tracks, please go to our website, DevJourney.info and click on the "Support Me on Patreon" button. Even the smallest contributions are giant steps toward a sustainable dev journey... journey! Thank you. And now back to today's guest. So Mathias, as you know, the show exists to help listeners understand what your story looked like and imagine how to shape their own future. So as usual on this show, let's go back to your beginnings. Where would you place the start of your DevJourney?

Mathias Verraes 2:51
Well, I was a kid in the 80s. And we had the TRS80 computer, which ran a version of Microsoft BASIC, it was called and nothing else a you couldn't buy games for it. Or maybe some actually, I think it had cartridges, but I never got them. So I did have a book that was explaining in a simple way how to how to program. So if I wanted to play games, I had to make my own games. So that's, that's where I started, all my friends had like Nintendo's but I was struggling away. And yeah, and that's sort of where we're started, I guess. And that was a that was fun. And I think the biggest thing I made was the sort of attempt at doing like a Space Invaders kind of thing. But it had all kinds of bugs where there was a book that I remember where if I, if I move the joystick to the or basically the spaceship to the edge of the screen, the game crashed. And instead of debugging that, I simply figured out that if I made the screen blank, it didn't crash. I don't know why. But if I made the screen blank, it didn't crash. And then I just made it a feature that it was like invisibility mode. If you go to the edge of the screen. You're invisible. And when you come back. So yeah, that's my first hack, I guess. But then I didn't actually I, I sort of stopped coding and got into music. And then I went to music school and there wasn't a lot of programming, except was something like I had a small BBS a bulletin board service that had sort of its own programming language as well, where I did some stuff with but nothing, nothing serious at all. And it's only when I was I was doing music and involved with different things and projects and I would make little websites for them, figuring out which smell and then start adding some coats. And, you know, that's, that's how I started. Again, I guess I, I started using open source tools and starting to modify them and starting to publish some extensions or modifications for like CMS and things. If I actually decided that people started offering me money, which I wasn't musician, people don't usually easily offer money. People started offering me money for like, yeah, nice, you know, this, this extension you made? Can you make something similar for me, and they wanted to pay me and so I started doing a bunch of these small gigs on the site. And, but then I started getting involved with this open source CMS and decided to start doing that professionally and started a company with one of the maintainers of the of that project for a while and web applications for clients, stuff like that. And basically, now I was a professional software developer.

Tim Bourguignon 6:13
If you went back to your to your 10 years old self, or that kid in the 80s, programming, Space Invaders, and told them, uh, you know, what, I'm going to do that professionally, later on in my life. What would that kid have said?

Mathias Verraes 6:28
Well, back then probably, I would have wanted that, right. Like, Microsoft was the most amazing thing in the world, because they have created this programming language. I had no idea of what people did with software. In fact, most people, like, I was the only kid that had a computer, right? So people weren't really aware of, of this and the potential and neither was I, but my dad was sort of using it to do some, like accounting stuff and small things, right. But it was also fascinating to me that this had endless possibilities. So as a kid, I would have imagined, yeah, this would be awesome to do, even though I didn't understand what it was. But then when I was a musician, and I started slowly, sort of rolling back into it, I was, at the same time rejecting it, I was trying not to become a programmer. It was like, No, I'm the sort of identity crisis, maybe I was, I am a musician. I'm just doing a bit of programming. Because you know, a website is great to promote your project or your finger. Yeah, I just need to learn this little thing here. So I can do this. I didn't buy books, because then I would be a real programmer. So but I did, like, I remember learning HTML from some. It was like a text document that I downloaded somewhere on a, on a on a BBS or maybe on a website, probably and, like, studying that whole thing. And that's how I learned I, I was refusing to properly learn it. Which made me very slow as well, right, which I didn't sort of realize, but I had, like this shared hosting thing that I, you know, you paid like a few euros, and you got a few megabytes and a small database and, and I would just write it in Notepad, upload the file test in production. Do it again, upload using FTP. I wasn't aware of editors or anything, because I wasn't deliberately trying not to get exposed to that world. But then, when I decided to actually like, who am I kidding, that's like this sort of the was this period where I struggled through this identity crisis and decided who am I kidding, I'm enjoying this. It's also I wasn't enjoying the music because I was the little money I was making I was making from advertising. So writing music for TV commercials and stuff like that. Which I found the very horrible environment where you were, there was everybody in the business, including the Secretary. Everybody wanted to be a creative. That's why they were they worked as a secretary as like a stepping stone. So everybody tried to have creative input on a project and prove that they were valuable or something like that. So it was a very sort of competitive space and then people would never agree on things and I remember once booking, booking a studio and booking musicians and we were in the recording session, and I got a phone call. Yeah. The some other person in some are committed He decided that they wanted a different direction anyway. So this was after everything was agreed on and demoed and ready to record. And people were hired and everything right, a lot of energy was wasted. And you have to, like, this is 20 seconds of music on a 32nd spot with dialogue and sound effects and logos and visuals, everything, the music is very much not the, it's just a bit of sort of, you know, create this emotion here for two seconds, and then move to as was engineering of, of music, there was nothing fun or creative. So I hated that. And because of that I didn't enjoy, like making my own music anymore, either it became too much of a job. And then software seemed like this world where either it works, or it doesn't. People would just describe what they want, and you would build it. We're all smart. Of course, I had some illusions that were broken later. But but that was sort of part of how I decided to switch. And then I had this for a long time, this sort of inferiority complex, right, all these people are, have studied engineering and know all this stuff. And I know nothing. And I was trying to read everything I could find and learn everything and go to conferences. And so I did a bit of catch up there. And then figured out that was a that was like the shock, of course, then you figure out that a lot of the software is a mess, is is, you know, has a lot of technical depth, nobody understands it, people don't know exactly what they want, they can't explain what they want. All of this, and, and I had another sort of crisis, like, oh, today, pick the wrong path here. But then I had by then I had sort of figured out, you know, if you if you get good at something, you enjoy it more, if you enjoy it more, you get better at it. So I figured, you know, I just have to learn how to refactor these things and start doing software design better, even when you know, everything works against you. So I really started focusing on that. And that, that I still enjoy, like taking a mess and start, you know, try to force it and manipulate it into a better position.

Tim Bourguignon 12:27
Before we get there, how do you think your background as a musician prepared you or didn't prepare you for what came next? Yeah. Do you have a view on that?

Mathias Verraes 12:41
I don't really know that people have told me Oh, yet. Musicians often become programmers. And they give reasons like, you know, they're used to, well, music has like a notation, which is an abstract language to express something else. So maybe there's a link there. It has structures and patterns. And, you know, ways that things I said, right, like the commercial, but I did a lot of music for films as well, which was not making money, but it was a lot more fun. But part of that is also engineering, right? There's this much time, there's this many frames, here, this thing is going to happen here, we want to build up this emotion or suggest something or there's like a whole bunch of things you want to do. And then there's this rich pattern language that you can use or subvert, right, which, you know, this is what aren't always us, either using things or subverting them or, or putting them in a different light. So you, you had all these things at your disposal, and you were very carefully trying to figure out how it all fits together and where to find you know, and learning to recognize patterns maybe like I don't know, just one example. But then Bonnie and Clyde in the movie, they use the banjo music for for the car chases. And for a long time a lot of movies used banjo music for Garcias it became a pattern. But but that's how it works, right? Like or the violence in cycle, right? The sort of sounds because of that movie become associated because it was so effective, of course, but it became associated with creating a certain atmosphere or something like that. So maybe, I don't know, maybe there's some relationship there and the patterns and the engineering mindset that you need force for writing music. And the same with pop music, right? It's it's also it's very constrained. It's needs to appeal. There needs to be hooks it needs to fit in to this form. Of course, there's a lot of room for creativity, but it's also a very sort of seeing structure and relationships and things. Maybe I'm just speculating what I was going to say what I did learn was a fraud. From the experience in the advertising world was more of the social aspect. Where, like, because people always wanted to have creative input, what I would do is I'd make a few different versions. And they would say, stupid things like, I want to have more melody in the drums. What exactly do you mean? Or is to have more of that? You know that, you know that that? Or that X factor or something? Right? They would, they would say stuff, that doesn't really mean. So I started preparing multiple versions, I would play them the worst version, maybe they would give nonsensical feedback, and they say, Oh, wait, let me try something. And then I, I pretended to make a new version, but I just rearranged or put up the next version, say, maybe this is worth more what you mean? Oh, yeah, that's exactly what I mean. Like, and they feel proud, because they have the ID. But so yeah, this sort of, you know, accepting that it's always a, you know, a social and political environment. And you need, you know, it's not enough to have a good idea, right, you need to be able to sell it or negotiated or compromiser. There's a lot of stuff that goes into designing systems, especially in large, complex environments.

Tim Bourguignon 16:22
And that comes back to what you were saying with the, the the users know what they want? Well,

Mathias Verraes 16:29
yeah, that's, of course, a lot more complicated than that.

Tim Bourguignon 16:35
They want they want more melody in the drums as well.

Mathias Verraes 16:39
Yeah, but they do have real problems, right. And we underestimate that they did, they will talk to us trying to speak our language, they'll try to, they'll say things like, you know, I need to, I need an extra column here. And they need a button here, or I need a form here or an extra field here. But that's not really the problem, right? They have a nightmare that another problem solving. And maybe why they need that is because they have some workflow that they do using spreadsheets and post it notes, where the real thing is happening. And they don't, their job is not imagining how that process could be part of the software. That's our job. But if we're only listening superficially, we add features, as opposed to start digging for for the real problem. And on top of that, like their job is, like, if we ask them, How does your thing work your domain, maybe you're I don't know, a trader or something in, in an investment bank, or whatever your domain is, right. And we ask them to explain it to us. But we have to, at the same time, teach them how to explain it, they can't just be expected, they can't just be expected to have like a very clear language and a way of explaining it, that immediately translates one on one to something we can coat. If it was like that, it would it would then coding would basically be sort of an advanced typist job. But, but it's really figuring out throughout all the noise, right? The finding your way through the noise and figuring out how to get to the real information, and then translating that into something that can help you build the thing. That is the real job. Which, I don't know, I never went to any kind of, you know, schooling for for this kind of thing. But I suspect that's not what they teach you there. I suspect they teach you, you know, programming languages and software engineering principles. And it's all very useful. But it's more than

Tim Bourguignon 18:59
that. Was my experience in the more languages then or none. And then that entirely, I have to revise this. A lot of flying programming languages, and a lot of understanding complex things that you couldn't know before. And so really jumping into a problem and just saying, Okay, how do we deal with this now, and not not knowing what the outcome could be not knowing which direction you could go and apprehending this thing, because this is more or less what we have now in our everyday job is you face something new every day, and then what and so on, but I'm going to show you could teach the apprehending a user problem bridging the gap, being more on the other side, etc. This is probably something you can learn on job. It's probably something you can learn by doing it. There's a little a few techniques. That's probably the place where you're going to start talking about DDD at some point. But it's it's a tool to do this. It's not something you can learn you know it and done, it's Well, each project is going to be different each time you're going to face human beings, you're going to have their have a Twitter to them, and it's going to be different. So there's a school for that whole curriculum, The School of Life. Exactly, exactly. And just as a very small tangent, but but so that's one of the things I hate and love about my job at the same time, which is when I search for something, and I can't find it. And I search again, and search and search and search, I still can't find can't find something. And that that there's this labor of love for each relationship with it, because what I cannot find it. But in the back of my mind, I know that the more I search for this thing, and the more time is spent doing this, that means I'm about to discover something huge, because obviously, I don't know the words, I'm not using the right words, it cannot be that I'm searching for something entirely new that nobody discovered yet. The most likely is I don't have the right words for that. And so I'm not searching for the right thing. And my word is going to be blown at some point. And I'm going to realize, I don't know this whole thing here. And it's gonna be fantastic. And this is a love hate relationship with this thing. Because obviously, it's a pain in the butt because you're not finding what you want. But at the same time, or how there's something new here. And that's what I discovered with talking to the user users is you're trying to speak their language, they're trying to speak your language, you don't understand each other. And at some point, you realize new language, new people new domain, whoa, and there's this thing opening up? And then you discover stuff.

Mathias Verraes 21:36
Yeah, yeah, absolutely. And the way to deal with that, right, you don't know, you know, there's something but you don't know the language? Well, part of it is in the in the preparation, right, the more you invest in learning different domains outside of just software, but like, finance and things like that. That's what that's something I've done, because, well, my job for the last 12 years has been to consult with organizations and do domain modeling and strategy with them, etc, to help them you know, understand their business domain, breached at to do engineering, make sure that the code looks like that, that it represents the same model, which eases the communication between domain experts and an engineering and architects. So what I did is I look, I consulted for an energy company, first thing I did was buy this huge book, like the Bible of energy trading, I didn't read all of it, but I tried to read enough to at least have a hint of okay, this is where, you know, here's some language, this is where this, this is the sort of thing that exists there. So I've been doing that sort of thing regularly. And then there's, you have this problem, you there is no language, it's not just language, right, you have no model for it. So, I will always try to sort of make my own models there and make my own language. Because in absence of having real language, at least I have something that can help me that is a reasoning tool, right? I started building making building blocks that I can use to address these sort of problems. But then, of course, also just trying to, you know, find it or find, like, put it out there, right, you can you can go, you can go try and talk to people. Like even in your own company, right? Often programmers are blocked because they assume, and maybe their environment suggests that they should always be at their desk programming. But just you know, go to the other office and talk to the people who are doing this thing and try to understand or buy them lunch or something. Try to understand what they do and what motivates them, and how they think about it, and what language they use. That helps a lot. And then if you have all three of these things. And then the final thing here is what Danella Meadows calls and exposure models today, like she was not talking about software engineering, but your understanding of something. So if you can for yourself, write down and draw how you think something works or how it is supposed to work or whatever. And then you go to other people. And you say, correct me if I'm wrong, right, invite them to give you feedback. And now you have dialogue right now. Now something interesting can happen. So that's sort of my roughly been my approach for this kind of thing.

Tim Bourguignon 24:51
That's pretty much how I was introduced to to domain driven design, which was by a consultant who told me basically what you wanted do is describe the model as you understand it, and then go to a domain expert. Use the words you describe the model with and tell them what's happening. And if you did it right, they're going to nod and know exactly what you're talking about and use the same word as you did to describe their job. And if you did it, right, this is this is what you did this is this is domain driven design or domain modeling accident.

Mathias Verraes 25:26
But if you didn't, ideally, you do that after you first get information from them, right. And then you do your own version, and then you go back to, or you just do models together with them, which is also very powerful.

Tim Bourguignon 25:39
And basically, if you didn't do it, right, or if you're somewhere in the process of iterating, toward this, they are going to correct you on words and saying no, you're not talking about about this blob, you're talking about a bloob here, which is two different things and then say, Oh, tell me about it. What's the difference between the two? And when do you use one, when do you do the other, or they're going to tell you well, but know that there's a middle step here. And then you're missing something. But basically, when when you reach this step, you're already using their words, they understand where you're going, they understand that you're speaking the same language, you just don't have the same grammar yet. And so you're nailing down the grammar. And this really blew my mind. And at that time, I was working for a bank. And it was in this financial institution, I didn't really understand at all what was discussed. And this really helped me to understand what's what's happening, and just go to a to one of the experts, talk to them, try to model something like you said, and make a lot of mistakes and try to figure out what was happening. And at some point, you realize you're speaking the same language, it's just Whoa,

Mathias Verraes 26:42
suddenly become easy. Yeah, yeah. And then if you can get that language in the in the artifacts in the Code and Documentation, tests, etc. Now it becomes tangible, right? The unique thing about I was discussing with Eric Evans recently, right, we have organic language like natural language, what we're speaking now, in domains, people evolve languages. organically, writer languages, social you, language has evolved to solve the problems of that group of that social group. So they will adapt words or come up with words or change meaning of words, or all these kinds of things to help them say the things that are important to them. So it's all very organic. And then in domain driven design and software, we try to build a language as it's a bit more formal, right? That is, well, programming languages are very formal languages. Of course, when we tried to translate this domain language into what we call in DDD a ubiquitous language, we're formalizing it. And then the discussion was somebody suggested that, well, if we can do this, for all aspects of business, have a more formal language, what if contracts are written in a much more formal mathematical language? That would make them you know, there will be no ambiguity, etc, it would be easier, you could understand them if you understand this, you know, contract programming language. But the thing that software does different that is very unique in the history, like Esperanto was a formal design language. But the thing that none of these languages ever had, was a was a compiler, or a type checker something that looks at it and say, yes, yes, it is, indeed, formally correct, according to this to these rules. And it's not just a programming language itself. But if you introduce a domain term in your code, and then you misspell it somewhere else, that's also a bug, right? That will also failed in the compiler or have some other unintended side effect. But at least there's this sort of force that pushes it into a level of formality that well, it's not that that didn't exist, like mathematicians have done this for centuries as well. Of course, they have formal language and they can if, like, mathematicians never disagree, right? If the calculation is correct, they agree if it's not correct, they figure it out. And then they agree. But it's a human, it's a human compiler. So it's, it's very limited and and slow, etc. So this is like the first time in history we've had this this kind of weird power and it's, I feel like we haven't even explored the edges of it. Of the possibilities there.

Tim Bourguignon 29:38
That is true and I'm laughing man in my beard because I'm thinking about a french french video from from a school teacher. And he just described that there is 13 one, three different ways of do a to do the the sound S in French, and 13 different ways to do it. And all of those are used, which, which is absolutely nuts, and speak about the newbie to be quitters language, if you start learning and you have 13 different ways to do this, and there's 26 letters in the alphabet, and each of us have different rules, this becomes a nightmare, first of all, but trying to nail this down toward something that is compiler friendly and could be really chair type checking cetera, would remove the whole creativity and fun of it. And so

Mathias Verraes 30:30
that's something written the well, it's this constant evolution. So the domain language is the domain is faced with new problems, right, the market changes, the competitors change the regulation changes, the users come with new creative ways that they need to use the system more abused the system, we have a new attack vectors, all of this, everything is always in motion. So the domain evolves, the language evolves constantly. So whenever you try to make a formal language for something, you are already fighting the battles of the past. By the time you have written down a formal language, it's for this to describe an old thing. In human languages, there's always people finding out Oh, that's not correct. French, or that's not correct. But there is no word in French or English and language that was not at some point, a mispronunciation or misspelling or misuse of something entirely different. The word awesome used to mean something that inspires or and, or is not necessarily good or bad, but it's this, or maybe it's evil, well, it can actually be bad. It could be, it's overwhelming, but it can be in a very scary really like, like, you watch the atom bomb explode. That's awesome. But now, that word means almost the opposite, right? It's something fun and cool. And this happens all the time, because the needs and the and sometimes even on purpose, right? Like subcultures, or communities develop language, on purpose to be different, and to, to exclude the other, like, young people will develop languages that are specifically different from their parents language, to, you know, to exclude them to, to shield to create community. So any kind of formal language is, is always chasing, chasing reality, which I find fascinating. But you have to take that as not, oh, it's a problem, because the domain is changing. And now we have to change the code No, that is your job, the domain will change the circumstances, the needs, the priorities will change, your job is to navigate that not not just play catch up, right? It can be provide for this opportunity, there could be potential for innovation there, where you you create, it sounds very abstract, right, but you create the space in your software, and then your systems and then your design that will allow for innovation to happen. that I find very, very fascinating. Part I, part of how you do that is being able to really understand the language as a design captured. I think we don't do that enough in software that we capture some terms will say, oh, there's a, I know, maybe it's a logistic system. There's an order and there's a shipment and there's a stock and we capture these these terms, but the real language has. It has phrasing, it has idioms, it has expressions, it has grammar, as you said, it has all these things. And there's also stuff hidden in maybe the domain sort of explains the process, right, then you write down all the nouns. But what they're really describing, maybe they don't even have a good model for it. There's something hiding in there, maybe the transition between two locations in the stock in the warehouse is more important than the actual location in terms of the model. Maybe that's where something is happening. Maybe the value is not that you have cars, but it's the availability of the cars, the fact that you can rent them out on a whim to your customers, right? That's where the real value so maybe your model shouldn't center around cars, but around availability, which is a subtle difference, but it gives you new language new building blocks. And then because now you have them model that actually works for the reality better. You can start seeing opportunities there. What if we optimize this thing that we didn't even have a name for before? Now we can sort of start having conversations about. So yes, language is organic and adapted problems. But us having this. On the one hand, the system that forces correctness of language, as sort of it has our back, right? And then playing with modeling and deliberately trying to figure out are there other ways or languages or building blocks or, or approaches to look at these problems? Can we capture that now we put it in our in our design, now it's, you know, it's type checked, etc Now, and now we can start playing with it again. We still I know this sounds very abstract, probably, but it's, it's real. That's a, that's fascinates me. I've seen it happen. I've been part of it, I've seen other people do it.

Tim Bourguignon 36:07
It's not that abstract. It is indeed, but I have a very real life example about this, which is when I learned German, so I'm French, and I learned German as a as an adult. And German is is a language, you can deconstruct, you can really see the particles, the words, how they were combined together, etc. And it really provides a different way of looking at things. So when you have a word that is combined with three different words, which all three have a meaning on their own, and are combined together, you start seeing the relationship between the two, and not just the words on their own. And this, this starts to to put things in a different light. And for the, for the, for the record, I started working for a French company, something like a year and a half ago, after spending 15 years in Germany and speaking only German oven, and started to reconstruct French words the same way and realizing doesn't work. And then asking myself, why what why doesn't work in French and French and seem weak works in German, and seeing the absence of relationship between the words, and this really tend to do something very real life related about what the language brings into your your way of looking at the word, the world? And this was fascinating. It's still fascinating to me.

Mathias Verraes 37:25
Yeah, yeah, absolutely. We have this in in science. Well, for a long time, people believed temperature was not something you could measure. It was subjective, you feel hot, and I feel cold, we're in the same room. But it's all subjective. And it took, there were many things we measured, we figured out how to measure long before we figured out how to measure temperature. And then once we do is, now we count and see it now it makes sense. But same with the metric system, right in ounces in foot sin inches, and all these things relate in weird and hard to understand ways. Whereas, you know, one cubic meter holds 1000 litres of water at well, not at zero degrees, because it expands but at like four degrees, weighs 1000 kilos, it's all part of the same system, which enables you to think about problems related with this stuff in a much easier way. Or Arabic numbering system is a numeral system is easier to reason about numbers and calculations cetera then the Roman numerals. So these are languages that that we invent that give us another way of looking at it, and that make a whole class of problems disappear and create new opportunities. But also metaphorically, right, I wrote a blog post about it was a company I was consulting for. I was supposed to be doing more of a more technical consulting around event sourcing. But they were doing they were paying copyright claims. So they were paying basically, if music is played on the radio or wherever, right at concerts, the people who wrote that music and the people who perform that music, have a right to be paid for that and but it's this messy, antiquated, antiquated system of claims and royalties and all of that. It's all very messy, but this startup tried to try to automate that and not depend on huge amount of human work for that. And they had this very system that was very complex because the problem was complex. But they also they were also experimenting with like how to automate because part of it is a trust system. The information could come from anywhere. There's In public sources, there's people, individuals, making claims that, you know, I wrote this work or this work was played somewhere. There are paid sources that do bit more curation on the on the data. So it was this sort of lots of different data sources. And then of course, you have a data quality problem. And you need to somehow look at all of that. And then what they did was sort of compare this data to see how how correct it was if two sources say that, okay, this claim applies to this finger or something, then another source says the same. And it's probably true. And also, they started realizing this, if this one source, if these two sources said and this sources it, then in general, that makes that source more trustworthy, that the data we get from it is in generally correct. So they tried to sort of put all that in the argument in the in the algorithm, but it was a mess, right? Only a few of the engineers really understood it. They didn't experience anything, it was just, you know, the problem is very complex. And therefore the solution, the code looks very, very complex. It was just sort of the normal pain of doing this. But we started doing a bunch of modeling, and I was listening to the language. And they kept saying, you know, trustworthy, so I said, Well, what's this trusting? Like, write it on a post it put it on the whiteboard? Let's talk about this. Right? What is trust? And we started coming up basically with a language in that that says trust as a as a finger in itself, right? It's not just data matching. They thought of it as a very technical way of data matching. The founders of the business, the who were domain experts in the copyright domain, but not domain experts in how do you build an automated system for doing copyrights? Right? They were not programs. But now that we started having conversations about why do we trust this source? And why do we trust this bit of information more, they started getting interested. So we started putting trust in the code as a as a value optic basically, right? Here's a number. This is the amount of trust we assigned to this unit of information, or this source or this individual or whatever. This was actually the business themselves, right? Those people now started seeing how to like, or we would ask questions, maybe like, what happens if this source is confirmed, or this bit of information is confirmed by this other source that we already trust? Right? We trust this source, level five, and this source with a level three, but it provides information, it is confirmed? How does that impact? So people from the business started basically drawing up an arithmetic of describing the evolution of trust? If you have a tree, and somebody else agrees with you, but they have a five, do you now have a four for example? Right? So you upgrade based? So that was an arithmetic now, that's something that engineers can put in code, right? That's just, that's just math. We started looking at what events impact. Trust, right, we started, what's the process was, so we can events are thing you can code, right? So there's this metaphor of trust. It is a metaphor, right? Trust is a human emotion that is hard to describe why, you know, I just met you do I trust you while something's I would trust you it but it's not a number. It's not an arithmetic. So it's, but we introduced that metaphor, I became a domain model we had done over time, we had like, you know, here's a different rules for different circumstances about how trust evolves. And now we can combine those rules into like strategy objects, right? Here's, here's a certain combination of rules for this situation, here's a combination of those rules for this situation. So it's a whole very rich domain model. Now, that made it very easy to play with and to understand and the business was like making that with us, as opposed to oh, that's the domestic, that's the engineering stuff. That's what I mean by, you know, getting that language and looking for that, that subtlety somewhere that nuance and trying to pinpoint it and taking it and labeling it and putting it on the whiteboard and having discussions and turning it into you're making the part of the artifact. And now you have something that is it's a higher abstraction level, right? We don't have to say, you know, a claim came in from that source with these parameters, etc. We can say, a claim with trust five, from a source which was like Get a much higher level or this set of rules this the the FUBAR strategy and the FUBAR strategy needs to have this rule from the bus strategy, something like that, you, you reason about is much higher order building blocks, you become more efficient, it's more understandable, but you start seeing opportunities for doing things that you couldn't even think of before. that I find extremely fascinating. That's, that's why I why I do this job.

Tim Bourguignon 45:31
And you're passionate, where you're talking about it with a big smile on your face and listen to was obviously cannot see it. That's definitely the place where I ask for advice and advice. But I'm going to do away with it today, because I wanted to come back something if because for the last half hour or so, we almost didn't touch or didn't speak about code. We spoke about all kinds of things, which is language related mold related the way we think that we would approach things, but none of that code. So if you if you went back to yourself as a musician, and not tell yourself how I'm going to be a programmer later, but tell him what you just told me this this story about languages but understanding the world about bridging gaps about bringing people from different domains together. Do you think you would still have fought against it? Or will?

Mathias Verraes 46:21
Oh, like that? Yeah, I I'm, I probably wouldn't have rejected it. Initially, I Well, also might have been too abstract, right? It would maybe sound like this distant, unachievable thing. Because at that time, I didn't really understand how you well, for music, it has just been like, you know, I had been to music school and I went to the study, etc. But I never really grasped. i My assumption was that if you spend enough time doing music, and being exposed and being in classes and studying for your exams, and practicing and playing with other people and writing music, that gradually you get better at that, which is not wrong. But it's when I switched, and I sort of felt his real need of I'm, you know, I'm a fraud here, right? I don't actually know anything about coding, I'm trying to make this my job. So I, I think it's only at that, in that time, I was like 20, something I don't know. 25 Maybe like while actually even later, maybe. But I started to try to understand how do you actually learn something, and I sort of developed models for myself. And I still do this every few years, because I why I'm restless. And I tend to get interested in many things. And then I'm like reading six books at the same time about completely different topics, but then I don't finish to finish any of them. And it frustrates me. So then every few years, I do like this modeling session with myself where I tried to figure out what do I really want to learn. And then I had a metamodel I have a mental model for that is, there's always something that I want to learn urgently, because there's an immediate needs that like, this will benefit me in a very short time. And maybe, you know, maybe you're building something using a new database, it pays off to get a book and like spend a few weeks trying to study that database, how it works, right? That's, that's the short term payoff. And then there's things where I know if I, for me, that was things like domain modeling, this will take probably a few years to get a lot better in it. But I will get sort of continuous value, the more I study it, the more I will be better at and I can combine it with practice. And I don't expect that in two weeks, I'll be an expert, but or professional or anything, but you know, it's a it's a longer term thing. And then I also made sure always that I had one thing that is sort of, I will never finish this, this is infinite it grows, the field grows faster than you can learn it, there's an infinite amount of potential complexity and learning. But I will spend a few years on that I don't expect to ever make money of that or do it as a job or have a direct use of it. But it's for the sake of learning for the joy of learning for them. And that has been different things over the years. For example, I learned Haskell that way the programming language. I could, you know, find a job and study and learned on the job and be good at it that way. But I was not interested in being a Haskell programmer. I was interested in the fact that it's it's the language that that some very smart mathematicians use to come up with very, like advanced abstractions on top of things that I was interested in. And I'll never reach the level loads of people I don't want to, but it taught me things about the nature of programming that you don't learn from just programming that you need sort of an entirely different theoretical angle. Now I'm sort of doing the same with, you know, how does our financial system work, which is also an infinite problem. And I'll never be really good in the way that people who had to dedicate their life to it, but it's something I only learned for the joy of learning, I will never sort of force myself but I keep going back to it and trying to find bits of insight and information.

Tim Bourguignon 50:35
Fascinating. So yeah. That was your question about code, I guess. But, but that was that was good enough. That was a really good answer. And anyway, um, thank you very much. It's been a blast diverging with you on on languages and, and all that around the models and not talking about programming, which

Mathias Verraes 50:56
feeds back into it right. In the end, you need to ship some code. So

Tim Bourguignon 51:03
it's a will be the best place to continue the discussion with you.

Mathias Verraes 51:07
Well, I'll be at NewCrafts next in Paris in May, I'll be at Domain Driven Design Europe, the conference will be organized in Amsterdam in June. I'll we also have an open space in the summer. I have a blog verace.net, where I talk about these kinds of things. And I'm on Twitter and Mastodon. So that's always a good place to nerd snipe me in a discussion on this stuff.

Tim Bourguignon 51:38
And I'll link all all this in the show notes. But yes, thank you very much. Thank you so much. I enjoyed this. And this has been another episode of developer's journey, and we'll see each other next week. Bye bye. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you liked the show, please share rate and review. It helps more listeners discover those stories. You can find the links to all the platforms the show appears on, on our website, DevJourney.info/subscribe. Creating the show every week takes a lot of time, energy, and of course money. Will you please help me continue bringing out those inspiring stories every week by pledging a small monthly donation? You'll find our patreon link at DevJourney.info/donate. And finally, don't hesitate to reach out and tell me how this week story is shaping your future. You can find me on Twitter at @timothep or per email [email protected].