Pre-recorded speaker:	This podcast is brought to you by An Event Apart. For over 15 years, An Event Apart conferences have been the best way to level up your skills, get inspiration from world-class experts, and learn what’s next in web design. An Event Apart is proud to introduce Online Together: Front-End Focus, a single-day online conference on Monday, August 17th with a focus on developing for the front end. You’ll hear insights from Ire Aderinokun, Aaron Gustafson, Henri Helvetica, Jeremy Keith, Una Kravets, and Dave Rupert discussing the latest in CSS advances, best practices in design principles, surviving audits, improving performance, and more. In addition to live message boards during the sessions, each session features a live moderated Q&A with the speaker. You’ll come away not only inspired, but ready to put new techniques and ideas immediately into practice. Greater Than Code listeners can save $50 off registration with promo code A E A G T C. Once again, that promo code is A E A G T C. So grab your spot and join us online Monday, August 17th. Visit AnEventApart.com to see the full agenda and register now.

Arty Starr:	Hi everyone. Welcome to episode 193 of Greater Than Code. I am Arty Starr and I'm here with my friend, Rein Henrichs.

Rein Henrichs:	Thanks Arty. And I am here with my friend, Jessica Kerr.

Jessica Kerr:	Good morning Rein and Arty and everyone else. And I am excited to introduce to you today Tudor Gîrba. Tudor is the CEO of Feenk [F E E N K], where he works with an amazing team to make the internal of software systems explainable. In the process they've invented moldable development, and are creating Glamorous Toolkit, a novel IDE that redefines how developers read code. And I love this because Tudor really thinks about code in a different way. and in a very like compassionate way as in, "Can we make the code be nicer to us?| I want to ask you how you got started on this mission, but we have a tradition on this show of starting out with tutor. What's your super power and how did you acquire it?

Tudor Girba:	Okay. I don't know if it's a super power, but certainly it is an obsession. Maybe that counts. It's called storytelling. That's my obsession.

Arty Starr:	How did you get interested in that?

Tudor Girba:	So, one time I remember myself standing in the middle of room field with people. I was in the university. I was speaking up against something that was happening at the university. I distinctly remember how I was trembling. Everything in me was shaking. And then when I went on to do a PhD and then I realized, I actually have to stand in for people as they're talking about whatever it is I'm thinking, and I started to, I have to convince them whatever I'm thinking has some sort of value. So that's where it all started. Then I thought, well, if I'm going to do that, I better get good at it. Or at least I better train it, not good at it. And so, yeah, that's what got me started. And then I never stopped.

Arty Starr:	You made a distinction. You said I need to train it, as opposed to get good at it.

Tudor Girba:	Right.

Arty Starr:	I like that because that's like an action you can take as opposed to like some condition, you can judge yourself on.

Tudor Girba:	Exactly. Like it's I can just going to do whatever is in my power to overcome something that again is under my control or should be my controlling, whether or not I tremble when I speak is my choice. It doesn't depend on anybody else. So that's something I can do. You know, then when you think about why, why is presenting ranking so high on the list of, the list of what people dread and it's about getting whatever you think and getting beyond yourself critic and putting it out there for other people to evaluate and to judge, you know, potentially to provide feedback.

Arty Starr:	And yet you're talking about presenting and I agree with you. And yet you open this with storytelling, which is a subset of presenting. You could just get up there and exhort people to care about multiple development.

Tudor Girba:	I could, I could, and I'm still doing it, but in private. When I'm, when I'm out in public, I'm very nice. But yes, indeed there is a difference. Storytelling is the content. You know, this idea of presenting is the vehicle is one of the situations there, but the same thing applies to whether or not you're going to write that tweet or whether or not you're going to write that blog post, whether or not you're going to commit knowing that somebody will review your code, whether or not you're going to open source a piece of code, knowing that somebody else will look at it and find that, I just need to clean it up a little bit before I put it out there. So like it became obvious or evident that I need to explicitly train the skill of getting something out of me, but then the content matters too. So once I started to give presentations and then, you know, at the end of the presentation, if there's no question that makes you think then perhaps you didn't manage to touch anybody. And so you need a vehicle that reaches, you know, a level higher than where you aimed at. And that's what I think storytelling is at the end. And there are many, many mediums to tell stories through, most of what moves us at the end are nothing but stories, stories that we tell our kids stories that we tell our partners, stories that we tell are, you know associates to come and join a certain cause and try to do something or stories that you tell somebody that you want to simply, you know, get somebody to follow what you think is appropriate. So, yeah, that's what I think about storytelling. And at some point along the way, I don't know exactly where I realized that when I'm writing code, I'm doing exactly that. I'm just telling a story. To different audiences is different, strange medium to tell a story with, but I'm now very much looking at software engineering as being a way of expressing stories.

Arty Starr:	And you want the code to be able to tell stories back.

Tudor Girba:	Right. So let's take something like conversations about domain driven design. Very often those, they emphasize a common language, right? As ubiquitous language through which two different people can share the same semantics. That's the idea of a language. And very often that language is made up, right? Because that's why there's no standard language. It used to have this assumption that if we will have a unified language we would be able to express everything about software, right. That was the idea of behind UML. And then it turned out that that's too limiting of a view. So now we are in a place where we are inventing the languages we're using to communicate with one another. And then it turns out that those languages create cultures, right? So the culture of a team is very much built around the language that we use to communicate with one another. And the kinds of things that we put in that language to communicate with one another. And so every time we go around a whiteboard, for example, and we draw something, right, we are making up some symbols and then we are associating some semantics of those symbols. Maybe, maybe there are some entities there and maybe they have some sort of a relationship. And so when, when I'm drawing that on the whiteboard, I'm communicating with the other ones, that's perfectly fine when I'm communicating about something that the system doesn't yet do, when I'm communicating about what I want the system to be in the future, essentially in communicating wish. This medium of expression is perfectly reasonable. However, given that, that representation, whatever I drew on a whiteboard was meaningful for me to communicate with another human. It follows that as soon as the idea that was represented on that whiteboard is implemented in the system. It follows that that system should also provide the stories that I told, because that representation that I used. And so those encodings of whatever semantics I have and whatever symbols I chose to draw on that whiteboard, they were meaningful. They captured a common understanding. Another human could relate to it. And so it should be the responsibility of the system to carry that representation forward. And it is the only way in which we will make systems be hospitable to other humans.

Arty Starr:	Does that mean your system can spit out UML diagrams at you?

Tudor Girba:	Definitely not. Right. As I said, there is no standardized language that will capture every idea that we have about software, right? There are many ways in which we can represent stories. The system has to accommodate whatever those ways are. So every time I joined a symbol, let's say that I have not like, cause I'm not, sometimes I have a smiley on whiteboard. And sometimes I have a frowny face on a whiteboard. A system should exactly show me a smiley and a frowny face because that's what I drew. And that's what people understood.

Jessica Kerr:	These themes. You're bringing up seem to persist in all kinds of contexts. And I heard you talking about, we've got these meanings that arise inside of something that we're trying to say, something that we're trying to communicate a dream or a wish that we want to happen. And we're like, "How do I express this idea?" Right? And there's this meaning that's already there that we try and express ourselves through some kind of symbolic thing and symbolic notation or some sort of way to communicate this. And then language is invented from these motivations. And then we come up with all these symbols that then we create culture that sort of emerges from the language. And then as we keep getting more and more rich vocabulary and symbols to communicate with those become shorthand quainter sort of to all of these meanings that are part of the fabric of our culture. And then we get so embedded in a certain set of languages and cultures that is already there. It makes it difficult then to go, how do, how do we reinvent these foundational kind of communication structures and this example of what we do in software development with designing a future and you know, on a whiteboard it's like, I put a smiley face on, on the board, right? A smiley face has meaning to us as humans already, right, from all these other contexts. And so what I hear you saying is you're trying to take all these meanings and these more native languages in ways we're trying to communicate with one another and have those same sort of symbolic meanings be representable in a code interface,

Tudor Girba:	Something like that. Exactly. If it did some job on the whiteboard and it must appear also in my development environment, there's no reason for it not to. If something is useful or again, let's imagine that I've just described an event on my whiteboard. And that event was depicted with this smiley face. Why doesn't that smiley face appear when I look at my log, why not, shouldn't be there. I shouldn't even be there because it's a representation and it's just data and data doesn't have a shape. That's an interesting thing about data. It's shapeless. It's just data, but we as humans, we always need a specific syntax. We always need a form, a shape to relate to anything that is abstract. There's no semantics without syntax, except in our brains, maybe, but as long as we are communicating with something like visual or me speaking to you. I'm speaking with something that is very, very concrete. And then you're building up the semantics of what I'm, what I was trying to convey on your ends of the communication. So because there is no we, we need this shape all the time and data doesn't have a shape and whenever we change the shape of something, we can significantly affect how another human can relate to it. So for example, let's take a, I have a table. If I can, you know, a table in Excel and I can look at that table as a bunch of rows and columns, or I can then take a little bit of time and I put a chart next to it, my brain will much faster associate meaning to the chart than to the table. That's the essence. And so the shape, right? We didn't change the data. We only changed how I look at it, which means that the shape of what data I'm looking at is essential. It's not optional, right? So you spoke about something like very interesting. So, you know, the language gets created within the context, but then one question for example, is what happens when you go out of that context to another place? How do we recreate that? And so until now we talked about the storytelling as the skill with which to formulate stories, but then there is the counterpart to it. And that's equally interesting. And that's the, let's say the reading skill, for example. So let's say, we can say, I want to write a story in this code so this code should tell you a story, for example, but then how I read it. I don't necessarily. I choose what I see when I read it's me. I choose. It's my ability, it's at that moment that every time I have data, and again like this was mumbo jumbo, about 10 years ago. But nowadays let's say with the advent of data science and everybody doing notebooks everywhere, and then slapping different visualizations onto data so that they can reason about whatever meaning they are trying to convey. We know that just this little exercise of taking a bit of time, creating a visualization about the thing that you trying to understand can completely change how you're going to relate to the insight or to the data that you're trying to understand. So it matters a great deal, whether or not you are showing, let's say very often people look or perceive code as being texts. Why? Because that's what you type, right? So what do people do when they're trying to consume code, they're going to read it. And here's the interesting thing, Maybe multiple interesting things. So one of the things that I'm asking people, developers is, do you agree that you're reading code for 50% or more of your time and the vast majority of developers do. And I spoke with more than 3000 by now, and there's good research in this space. And it's good research that they, that goes back for decades, not literally 1979 was the first mentioning of this issue that I could find. But then here's the other question. I'm asking people. So when was the last time you talked about how you read code, so what about the code that you read, but about how you do the reading? And it turns out this is not a subject conversation. This is interesting because 50% or more means the single largest expense. They cannot be anything that is more expensive than this. We're never challenging how we're spending the budget, right? This is tight. Nobody have it, and that's the interesting thing. The beauty of it is that we developers, we already have, the budget is already been that it's already allocated it's there. And it's a single expense, the single largest expense we have. And we never talk about it. You never talk about it. It's not explicit. If there's an explicit, you have never optimized it single largest expense. Right. It's amazing. So go one step further, say, so what does it mean when I say, well, that is you don't talk about it. It's not explicit. Where does the reading happen today. In an editor, editor. This was some medium that was not conceived to somebody to read. In fact, Cody is likely the, or one of these single items of you know, information of data that we are actually reading in an editor. We're really everything else, somewhere else in a dedicated environment that is specifically targeted and designed for people to consume, but not code. And that's a problem because it's the single largest expense we are having. And there is another way to look at it. So code is not text, code is data, everything around it is data ever since we have stored the program onto the same tape onto which the data was stored. And we put it into that big machine ever since that moment programs or codes was data. So this is not a nothing changed. This is not new. The problem is that we still looking at it as if it's text and because we're looking at it as if it's text and we assume that the only way to consume it is by us reading it line by line. But once you escape that perspective, once you look at it as data about which you want to formulate stories, and there's a very interesting exercise and a very interesting skill that you can actually train to project, imagine stories and try to see if those stories are real about everything around your system. And so there is a skill of, I have a problem and I will say, "Ooh, for this specific problem, I would love it to see it like this." I would love to have a tool that shows me, shows me these kinds of story. And then once I, and I, I will take the time, what solve the problem. I would just build a tool that will visualize that problem or that piece of, you know, could be code, It could be some sort of a dependency [inaudible] 17:38 some yeah, some dependency. It could be something happening in, you know, in a run time. Everything is data and everything can be visualized in some, some shape. And I will take the, to create that shape and only when my brain will have enjoyed that shape, only then will I start approaching the problem? So here's another thing that is bothering me. We started the conversation and then we, we kind of realized before the podcast, we kind of realize the whole world goes through amazing transformation right now, right? It's just, everything is upside down for about, for actually not just one reason but a couple, but we developers, we are the least impacted, right? For many of us, nothing really changed. So, you know, whatever work we were doing in December, we're still doing today. There's not a lot of change. So act to that that we are ridiculously well-paid, we're never in a harm's way or almost, or most of us are never there. We're ridiculously privileged. We should be blissful all the time, that we should be enjoying everything we're doing all the time. And the fact that we are not, it means that something is really, really wrong because like, we are the most privileged class of people in the world today. And we are not happy. Or most people, most developers are not happy on a daily basis. Something is so wrong because if we don't get these people to be happy all the time, what chances do we, everybody does everybody else, they have no chance. I mean, must be doing something that is fundamentally wrong. And that's why my proposition, or our proposition is we should optimize for that happiness. We have to optimize for that happiness. And that's why I will not start solving the problem until my brain is at complete ease as in "Woo, I really like this problem". When I get a bug, I want to enjoy how the bug feels like, and then I will solve it. And you know, what's fascinating about this because it sounds like, you know, sounds like I'm smoking something, but I promise you I'm not. But the thing is that when you do that, when your mind is at ease, you can focus on that problem with such an amazing energy, that your productivity skyrocket. There is a correlation there needs to not, this is it's a false choice to say, we need to choose between happiness and productivity. Just like there's a false choice between, you know, health and privacy for example, In the, in the case of the Corona crisis. There are ways to look at problems to actually have all of them. And this is one of it, the way the industry looks at software today is broken fundamentally broken. And it might not even really be such a big issue if we wouldn't touch everybody else's lives because we are not only a super privileged class of people. Everybody is impacted by us.

Jessica Kerr:	Yeah. We are super powerful class, we're crafting the worlds that other people are living in every time they open their computer, or phone or.

Tudor Girba:	Right. We're setting it up. We're not setting everybody up for happiness. That's such a terrible thing. And it's such a missed opportunity. And as I said, if this would just be about happiness, maybe nobody would, you know, it wouldn't move the needle. But what we found in our work is that it correlates with economics. You literally can get more profitable if you actually optimize for the individual happiness of a developer. And I'm not just, I'm not talking about the perks that you put in the fridge. Those are irrelevant. I'm literally talking about enjoying every single bug. That's what I'm talking about

Arty Starr:	Specifically the happiness in our work, the happiness, when your mind is at ease and smooth and really able to focus on the best way to solve a problem.

Tudor Girba:	Exactly. Right. And then no tasks. And then yes. So when you look at, so let's look at the trajectory a little bit. So at first we had code and then we were a little bit struggling and then we had to test this code, right? So then we say, "Ooh, we transformed". We took the drudgery. You know, like we were, the clicking part was really so tedious and still require no braids. In fact, it was killing brain cells. You know, when people are clicking their way in order to ensure regression properties, this is like, it's, you're killing any ability of creating anything at that moment. So when we have moved to those tests to stop being done by human, when we delegated into a machine. We enable, we can basically empowered those people that would otherwise be spending their energy clicking. We empower them to create, and there are so many things to create. Like at the beginning, people thought, ":Oh, this means that we will kill jobs". And it turns out that we actually created more jobs. So it has nothing to do with that. Right. And then let's move a step forward. Cause then we had, we started to work. Like if you go towards infrastructure as code, right. All, a lot of thinking, a whole new meaning, waiting.

Arty Starr:	It just affects everything.

Tudor Girba:	Right. But a whole new way of value God created. Right. And a new way of thinking was possible. What's essentially, you could add a speed off commit. You could test something, you could put it out there in the real world. You could materialize on every single commitment. That's a, that's an amazing fit, right? And when something becomes code something amazing happens. So the next thing that will happen, and the next major thing that will happen is the tools, the tools would be actually interacted with, with our code. Those will become code, and that's the next major or what I believe to be the next major revolution, because it's, this, these tools will free us from the specific shape in which we have stored, just think about it. Like every time you're reading code, you're literally doing it in a way that data was stored you're reading. The format in which you have stored data. And that's never a good idea, right? All apps in the world today, what they do is it, it they take some data and then they visualize in a completely different way than it was stored. In fact, most users of apps today, they make much better decisions than they were a decade ago and they never ever see the raw data. That's the fascinating thing, right? We can, and we can increase the coverage that our brain can literally deal with gigabytes or terabytes of data, almost at the speed of thought, just because we take a bit of time and we invest in this translation layer, very thin translational layer that takes lots of computation and takes care of how this competition has been presented to somebody. That's the job of the tool. That's the job of the environment through which you go and interact, and that's not a default choice. It must be an explicit choice. It must be an architected choice because the choice of those tools is as important as any other major choice you make about your system. So this now goes back to to Marshall McLuhan and his idea that, you know, the tools that we create end up influencing how we see the world. What is interesting about that is the corollary, it's just like with Conway's law, right? The interesting is the color. Like what do you do with it once you, once it's your place? What we learned from McLuhan and his, his students is that we have to be very careful with the kinds of tools that we expose ourselves to, because they will determine the way we're going to think, right? Like if we care about privacy, right? And there's a great deal where you put your data and the way you are going to be incentivized to put the data in one way or another is going to be highly influenced by the interface that you actually interacted.

Arty Starr:	Or how easy it is to understand how easy it is to put the data there.

Tudor Girba:	Right.

Arty Starr:	And then if it winds up being really easy to put your data on Facebook, then you'll stop caring about privacy. Because if you did care, you'd have to do something about that.

Tudor Girba:	Precisely. Now, just think of how do developers choose their development environment. It's a default choice. It's either this or that one. But if you, if you stay like two meters away, there's almost no way for you to distinguish is this like this code, or is it Intelege? There's no way, like, they're all, both black. They both have the same kind of,

Arty Starr:	Hey, you can totally tell that from Emax.

Tudor Girba:	You can. Exactly. Because they will use, they will use a green- a green characters.

	[laugh]

Tudor Girba:	No, I'm kidding. Actually, Emax, I mean, Emax was a revolution that just even quite happen, It should have, but there wasn't an amazing system because at the time, right, you have one medium that you could change while you were working with it. And we think that this is an essential property of the medium that you have to work with. Because in the end, that's, that's what makes that's what's make computers amazing. Right? That's what makes the phone exciting is that because you have all these little bubbles, all looking completely differently and they can, you can interact with it. Different parts of your interest will be served by one shape or the other shape. So that machine that is otherwise rigid. It actually molds to whatever you're interested in. And then of course there is many position power there, right? Like we saw with, as we were talking about, you know, privacy apps and they incentivize something and you're doing that something. And then only to see afterwards that there are interesting side effects that you have never considered because you were never exposed to them. Right. They always , they were always there. And they were always part of the design. You as a user, you are just not never sensitized. It was never made explicit for you. And as a consequence we end up doing, not particularly smart decisions. Now, when we are creating systems, there is an amazing power that comes with the shape of our tools and when not creating systems, we already have that ability. We already possess the ability of changing how this rigid device appears to us. And so what we are saying is that a real environment should make it incredibly easy for you to mold that shape, to whatever perspective you're interested in any time you're looking at it. And this is how by doing this as well, we call this is why we say moldable development. We say that for every single problem and want to change these rigid device so that it shows me something and I'm completely at ease with. And then I'm going to approach the problem.

Rein Henrichs:	The way I'm processing this idea is that you create a new metaphor for the underlying data on the fly and that new metaphor lets you manipulate and perceive interact with that data in a way that's more suitable to the problem you're trying to solve.

Tudor Girba:	Absolutely for every single problem, we're going to build maybe dozens of tools per day. But it also means is that now the cost of the tool for this to be economically viable, the cost of a tool must be almost zero. And then again, might sound really like if you look at a typical ID today, you're saying, well, how much does it cost to create, depends on effort to create a plugin for it? And it might still be measured in days, right?

Arty Starr:	But I could see it like a snipit In a few minutes.

Tudor Girba:	Exactly. Right.

Arty Starr:	Emax Macro.

Tudor Girba:	Precisely.

Rein Henrichs:	If you look at the amount of time that developers are willing to spend making metaphors in the code, that better model the problem, then I think it's reasonable to do that at the metal level higher as well.

Tudor Girba:	Yes. Yeah. I agree. I never thought about this, but I really like that parallel that's sounds really cool. Exactly.

Arty Starr:	That's.

Tudor Girba:	Exactly.

Arty Starr:	Because we'll spend a lot of time working on our beautiful abstraction.

Rein Henrichs:	Yeah. Sure. Every all development is, is finding better metaphors for things and then writing them in our editors, right.

Tudor Girba:	Exactly. Right. And so what's interesting is like you're hitting a very interesting point that I'm still struggling to express. Let's see if I can manage now. So we are building abstractions. Right. But the abstractions, whenever we, whenever we have a napkin next to us and we want to communicate with somebody, that abstraction never looks like code, it looks like something completely different, right. But when we go to code, then boom it's always code because, why? It's not because we want to, it's because there is no other choice. So you know, we think we very much thinking, you know, we like this building and they will come type of thing. So we say, well, what would developers do once they would have the possibility of let's say, let's imagine that we can, you can generate pictures. Like you wish them about your current system. That's almost zero cost. What will happen then? So we're actually working like that since five years. We're building glamorous toolkit, which is the moldable development environment that we are designing. We are building it following this metaphor. And by now we have literally thousands of different views that shift together with the tool. It completely changed the way. For example, I look at programming, so it started by me wanting to tell a story. But then now I realized the way I think about the problems and the kinds of new domain it's completely influenced by those little views that we are creating all the time. And so I was talking about this, the, for economics to work, the cost of a tool of a tool must be almost zero. Right? So we saw it in Emax. It's absolutely. It was by design. It was meant to be like this and that's beautiful. But you know, I was talking about these other things that became code and they became codo, so I mean, TesCisco existed for a long time, but only when it was possible to do it cheaply only then it affected the economics only then, and then together with this, it affected the option. Only one infrastructure became cheaply capturable as code only then the behavior of people using them changed. And the same thing will happen with tools. So the design of the tool has to fundamentally change. And so what we are showing the glamorous toolkit is here's an actual environment that you can actually go and use and apply to real problems, then you can see how it feels when the, when it is designed specifically or explicitly to optimize with this little cost.

Arty Starr:	See how it feels, that's important.

Rein Henrichs:	So this whole time, while you've been talking, I've been trying to pay attention, but also my brain keeps wandering off to this idea that I've been having for a while now about how editors work. And so far, we've been talking about how we could change the form of the interaction with our code, but we haven't been talking about whether the interaction itself could change. And what I mean by that is historically editing code has used the Shannon communication model, which is to say that there is two agents and they both perceive and respond to information, communications, but they deal with it sequentially. I say something, you understand it and say something to me. I understand it. And say something to you and so on. And so it's this sequential, non-parallel right. In the real world a lot of what happens is that these interactions are concurrent. Multiple agents are all perceiving and interacting at the same time. So for example, in the operating room, I can't get the patient to stop being alive while I figure out how to solve the problem, right. Surgeons have to operate in real time, right? It's a joint activity. So there's this idea of joint activity, which is that all of the agents and the activity are all doing stuff at the same time. And we're starting to see this. And I think it's happening sort of by accident, but we're starting to see this in editors. So for example, asynchronous syntax checking, when you get a little pop up while you're editing something else with another piece of code turns red, right? That's a joint activity. The syntax checker is operating concurrently with you editing the text, right? A really good example of this today is in Rust. There's this tool called the Rust analyzer, which is like a type checker type thing. And what it will do in your editor is it will actually annotate code with types on the fly as you're going. So you'll be typing in code over here. And then the compiler will know more about this type over here. Will, can infer a type and then they'll just see, you'll stick it in over there. And so this is what's happening now is that editing code is becoming a joint activity where I am operating on the code and the editor, but the editor is also operating on me. And this is all happening at the same time. It's no longer I do a thing. I wait for a response. I do a thing. I wait, it's joint now. And so another example of this might be like, if you're editing an animation, like a pixel art animation, and you have a little window that shows the result of your animation as you're going. So you see changes up there immediately. That's a joint activity, right? I'm messing with pixels over here, but simultaneously concurrently, the representation of the animation is changing a lot. So I guess my question is if we think about editing as possibly being a joint activity where everything you're talking about, isn't restricted to request response cycles. If I can have multiple models, multiple views, you know, metaphors operating at the same time and giving me feedback asynchronously, what does that look like?

Tudor Girba:	That's the thing when you do not have, when there is no single language to capture, you know, meaning from one to another, there are always going to be multiple perspectives to look at the same phenomenon, whatever that is, it could be code. It could be data and we, we will be interested in it from multiple different perspectives. For multiple different reasons, let's say I'm looking at a code and somebody is looking at it from all let's see, is the design proper? Is it, are we capturing this thing that we draw on the whiteboard, but somebody else will look at it and look, what about security? Somebody else will look at it. So what about performance? Three different perspectives, right? And these are coarse grain when you zoom in, you have, you know, orders of magnitude more. So there is no single perspective to interact with code. There are always many, and there are always valid. That's the interesting thing, cause there's no single truth first. And then there is no single perspective to assimilate that one, there's no single truth, that's wrong, but its the truth. But I was more thinking of that. There is no single representation of truth. That is the only one that matters. There are always many, in fact there is super power. There's a super power in controlling how that view me. So you are, for example, talking about I'm editing code over here and then the rendering updates live over there. Right. But then what is that rendering? Because maybe that rendering should have texture, but maybe I'm actually caring only about the wires. Maybe I care about how many polygons there are. Maybe I care about all sorts of other things that are equally interesting, right? The end user sees one thing, but we, as creators, we will see so many other things, right? So when I look at a painting, I will see the finished thing, but the painter will care about you know, how the, you know, the colors were, you know, what kind of colors, what kind of pencil, what kind of canvas, what kind of, you know, how was the light at that time? Also many things, you know, what music was playing so that I can go into the mood so that I can combine the things, all sorts of things are relevant for the creators that might not necessarily be relevant for the users, but that doesn't make those perspectives not interesting. In fact, that's exactly what makes the difference between joy and, you know, drudgery.

Jessica Kerr:	So we changed the shape. We change, how we relate to it, we change the shape, we change the stories that we interpret from it. And all the leverage of being able to increase the amount of meaning we can get through these various perspectives, simultaneous perspectives are ways that we can potentially exponentially increase the communication bandwidth and capability just in terms of raw human technology, interfacing by rethinking things at this key junction point of interfaces. So I wanted to ask you a question because there's a fundamental leap that you're making here from we can look at interfaces in terms of like, "Hey, let's add some more metaphors in shape around our text". It's fundamentally different to go, "Okay, text. Let's just set that aside and think about other visual representations from things". And we've had text-based languages for for a long time, we'll say, but it just becomes kind of a given then if that's how you do things. And so even when we iterate, we still stay inside that same paradigm. And I start thinking about things that we've done the same way for a long time too, like, like sheet music, right? Like we've had sheet music notation, it's just been done that way, right. So what do you do when you're learning music? You learn, you learn sheet music, but sheet music is just this thing we invented and music doesn't have any inherent sheet music like properties and the system for mapping notes and [laughs] flats. And all this stuff that we do is actually kind of crazy, right? Yet these things that become the sort of commoditized ideas that become invisible to us as sort of the baseline language that we build everything on top of it seems difficult to get to this point where we go, let's rethink these fundamentals around communication at this abstract level. And maybe we shouldn't do texts and getting to these other areas of exploration. And we started this talk. You were talking about presenting and the difficulty.

Arty Starr:	Maybe we shouldn't do only Text.

Jessica Kerr:	Say that again.

Arty Starr:	You said maybe we shouldn't do texts. Maybe we shouldn't do only texts.

Jessica Kerr:	Maybe we shouldn't only do text. Yes. Because all of those perspectives are additive at the same time when we're thinking primarily in text, it seems like that's potentially constraining. Or if we're thinking in terms of sheet music, the same thing kind of happens because we change the shape. We change how we relate to it. We change the kind of building blocks in our mind that allow us to work with it too. So maybe having a fundamental text-based programming structure creates fundamental constraints in how we think about interfaces, where if we had different sort of atomic units to work with fundamentally operated differently, that were more say geometric in nature, that programming and the interfaces for it could look substantially different if we had different building blocks. But my question was abandoning something as fundamental as text or as fundamental as sheet music, is a pretty significant leap for anyone to make. And you were talking about the difficulty of presenting new ideas out there, or taking ideas that were fuzziness in your head and trying to communicate new, innovative out of the box thinking and the struggles of that. What kind of things can we do to encourage that sort of out of the box, thinking encourage the abandonment of, you know, fundamental constructs, even just for sake of I'm not abandoned, that's the wrong word?

Arty Starr:	Augment.

Jessica Kerr:	Well, I don't think it's augment, it's considered boldly variant alternatives consider a paradigm shifting alternatives. How do we encourage and support that type of ideation?

Arty Starr:	Well, we can start with you don't take their text away. You add to it. And you don't say there is one solution that's better than text for everything because there isn't, especially not the current world, which is full of developers who understand text. You say what would be a better perspective for this problem. And then you create a glamorous toolkit.

Tudor Gîrba:	You're right. So let's, let's say there are a couple of things that I really like this, the idea is that you formulated, so let's take the one by one. First one of the things that we are probably the, the largest thing that we're contributing to the field of software engineering is that we're distinguishing between the way we write and the way we read those two things are not the same. They have never been the same in any other fields, but they are the same in ours, or they are, it's assumed that it's the same and that's wrong, or that's what we think is wrong. So what we are focused on is on reinventing how you're reading, because that's the one that we take for granted. From the writing side, we have, there's been a lot of work. Everything is about how do you create things, parse and parse them, by the way, that's why we're creating software at an exponentially, you know, like the speed of creating software, it grows, it accelerates year over year. So we are good at it. Although the problem is that there is, we can't move the systems that we're creating, like, we are unable to seem to. We seem to be unable to recycle the system that we are creating the putting out there. So what we are saying, isn't what we are fundamentally working on and proposing is that we are changing how we are reading and the reading part, that one is almost, or very often before that one text is not the appropriate representation. It is a very interesting one. It is a very detailed one, very often, not the interesting one. So it's not the model of interest in that specific context that I'm looking at. So that's, that's one, first of all, when, when we think about, they were talking about what happens when the building blocks completely change, and then I completely agree, we definitely have to go and think about that, but there's a difference between how we are capturing all details that are relevant for something to function in all the cases and the use case in which I care about the very specific problem. My bug is not the same. These are not the same things. So one of the things that the people are like more recently, we're trying to explain what it is that we're doing. Cause we've been working for so long, are kind of isolated in our little with our little idea. And now the glamorous look, it becomes a real thing. It's a real product. People can download, play with it and our ideas become material. Now we're trying to focus more on what is it that we're doing? And we're having, we're still struggling with that. One of the things that we thought about is, or that we are, that we verbalized recently, is that, you know, programming, you can look at these as, you know, implementation, you know, you, you, you care or somebody else's bidding. So somebody specifies, right. We even have these idea that there is a specification that you then implement, right? The assumption there is that the specification has everything. And then the only thing he needs to do so happened is that for you, the typist to type it in and then it's done, right? Which of course is not what happens because specification or what we think specification is, is never complete. And because it's never complete somebody, we, the developer, the typist, right, has to put those details in that's a creative work, because then it turns out that when you're doing this, it's actually, you're uncovering all sorts of problems, macro problems, not only the tiny things. So there is no way around this is, you know, looking at software and programming as implementation is probably wrong. Looking at it as a creation is completely different. It's probably more appropriate, but then it also brings you into competitive space because then when you look at it as creation, it basically that your programming is true. A program is a materialization of thought, you're getting the thought and you're expressing it. And then you're, you're capturing into some form, right? And that form today, the most pervasive form in which we're capturing those thoughts, is through texts, and that's, that's still an amazing technology, right? That enabled a whole lot of things to happen. So we shouldn't discard it. But the problem is today, right? I was talking about how we are creating systems faster and faster, but we are unable to move existing ones. We are unable to recycle old systems, right? So from that perspective, we're actually not really behaving any differently from the plastic industry because it's not sustainable what we're doing. But what does it mean to recycle the system? It means you take it apart and refurbish it for your purposes, but before you can take a system apart, your first, have to understand the parts. If our ability to understand those parts depends on our ability to read. And we have a fundamental problem because that's a constant, that's kept at a constant speed. So you're trying to imagine exponential growth with something like where the recyclability speed that is always constant. So that's a problem. And it's a problem that we have to fix because otherwise our world is not going to be sustainable. And so what happens is that we actually end up creating these thoughts that are only readable by the machine, but never by other humans. And that's a real problem, right? Because there's an amazing thing, right. Of creating this common understanding of the world, right? And so your thoughts and my thoughts, they are all together now, you know, they coexistence now, but I will never get to understand somebody else's thoughts. Cause what it means when it cannot go into a system and understand what is in there. And, you know, if you look at it from the other perspective, there's, we're building the whole world on top of software and software behaves, not unlike laws, right? Only as a laws and law enforcement at the same time, if you're not able to understand what those laws are and what the informs, the actions we see more recent events is that never leads to a good thing. When, when the, you know, when people that are subject to the actions of law enforcement have no access to how those actions are being performed. When we are building these worlds in which is our systems are basically right only essentially. And then the only, our only chance is to build another box on top of the previous box. Then we have this problem and we can only change it. If we are fixing the reading skill, not the writing one. The writing one is still important. Yes. We have to think of new ways of capturing code and text is definitely not the only way. And if you, for example, look at work that is happening in dynamic land, some beautiful, beautiful ideas of how one can not only express thought, but live in the middle of thought, because there they think the computer is a building. And so you in you're in it and you interact with that building and you program the building while being the building. And that's an amazing thing. But until then we still have these tons of software that is piling up around us and we have to improve. It is it's imperative that we improve our reading ability, the ability to understand and relate and refurbish, right? Somebody else's thoughts. And that's where the non textual representation of code is essential.

Jessica Kerr:	I was thinking about my question with regards to innovation and kind of what's on my mind right now and your contrast of reading and writing, you know, I think about graphic sort of write code visually sorts of paradigm things to then a difficult way to write code comparatively to text. Once the code is written, being able to visualize it and a bunch of different ways sees how it's running and from a whole bunch of different perspectives is useful. Even if you know the code and there's texts, I can basically do that without having the same difficulty of being, you know, having to edit through these same interfaces that are designed for reading. So separating these writing and reading concerns allows us to make that kind of multi-perspective viewing of what's going on as I'm like poking in the box in another way. As I, as I look at the problems and challenges and things we face right now in this current crisis, there's a tremendous need for innovation in a whole bunch of different areas. I have concern about people's ability to sort of like be able to think outside the box, to go back to fundamentals and rethink some of these things because of these baked in languages, paradigms, cultures that have always been there that way for so long. And I'm wondering if maybe some of these fundamental things of, change the shape, change the perspective, what are these fundamental things we're trying to optimize for? What are these, some of these fundamentals around communication that maybe we could get some clarity around what these first principles are that we're trying to optimize for? What does it mean to optimize for happiness? What if we start there assume that the economics will end up aligning with it and we start there and design the whole system. What do we come up with? What if we just allow ourselves space to dream, allow ourselves space to challenge some of these fundamental things that have always been there and explore different directions and see what we come up with. And I think about what this multi-perspective view, even on the putting code into the system in the same way that Java enabled lots of rich innovation in terms of the tooling that, you know, relied on all the static typing stuff. So we had lots of innovation in tool support because Java was designed to help with those sorts of things that likewise, if we designed our input infrastructure to give you flexibility in being able to do multi representation, if that was something that you were designing for in terms of how you input the data, it seems like that creates opportunity for new sorts of language innovation on input that is designed to enable or reduce the amount of constraints around multi representation on the outcome visualization side. Like, I feel like we should still be looking at those kinds of things together because one can still compliment and work with the other, but we've never really, really explored a whole lot that direction, especially not as an industry. And I feel like right now we need to be doing a lot of collaborative industry research sort of stuff, but there's not really a whole lot of momentum in context for that. And it needs to sort of like start appearing and accelerating more. I feel like just innovation in general and us, as you were saying, we're in this position of privilege, a lot of influence and power to be able to do things that other people can't. So what are we going to do with that? I feel like driving innovation for it and figuring out how to create environments where a lot of these new ideas can flourish is super important right now.

Tudor Gîrba:	I think so too. And I also think that the environments are not just technical, but organizational in nature as well. So for example, there's this shift that happened right? Forcefully recently, everybody started working remotely. And one of the things that I hear a lot from this experience is that people say that meetings are there are much harder now. And so one thing that is, you know, there's very few people that actually considered the idea that, why have a meeting in the first place. And that's, that's an interesting thing because we are a remote company. And one of the things we found during the last month is that literally nothing changed for us didn't change anything. Although everything changed for the individuals, like a lot of things changed for the individuals, nothing changed in the way we work now, just remote, the remote part is not enough because remote work is a new medium, and every new medium comes with constraints, but also new opportunities. If you're just trying to map something that happens in another medium, on a new medium, and just doesn't work, if you're just taking your office work and then mapping it onto your under the remote, the remote medium, it's just, there's like impotence mismatch. So it's just never going to work. So in our case, for example, we have remote meetings. We have no, sorry there work remote. We have no meetings. We have no backlog estimations. And we somehow create something together. The interesting thing here is, again, we're saying the individual comes first and the organization has to mold itself around the individual. And that's one of the ideas about optimizing for happiness, because happiness is individual. It's not, it's personal. It's not, it's not a group thing. And the way I'm happy, it's going to be different from the way my colleague is going to be happy. Let's say, if somebody has a family, your constraints in the way, you will want to maybe live your life. And the schedule that you'll have, it's going to be really, really different than somebody that just wants to travel the world. And then the other thing that we noticed with literally, we noticed that, so this schedule completely changed. Like the personal schedule completely changed over the last few months, but because it was never required for anybody to be in a place, it has no influence on anything. Again, there's no trade off here between productivity and happiness. It is not the trade off, you know, once we understand where is happiness not optimized? Where, where, where is it? When does it come in contradiction with reality. And then we go and optimize for that, designee for that. Cause an organization doesn't just happen. You designed it. It's something that you create, it comes with constraints and so. The other thing about this is, so it looks like we're doing everybody can do literally whatever they want, but first of all, we don't have a backlog. There's all centralized order backlog. There is those strings. Literally anybody can do whatever they want, but at the end of the day, we have to produce something that is of meaning. Once everybody wants to do that they somehow magically find ways to coordinate one another, but there is one thing we do put in place because like I just described things that we took away from it. And the one thing that we took in place is storytelling. Because the way I will try to convince somebody to work with me on my idea, and I'm the CEO and I cannot tell anybody to do something. I have to convince them that this is a good idea or, not that is a good idea, but there is an idea that they would like to have, to see if it's a good or not, if it's good or not. But the way I will convince somebody to work on my idea is I have to sell them on that idea. Right? So if they don't buy into it, they just not going to do it or score. Even if they're gone, they will implement it. But I don't want them to implement. I want them to create with me. And so, because that's what makes me happy, right? When, when I get to create and when I see creation happening, where I am part of it, and I love that idea of creation, of being a dialogue and not being me saying some sort of command and then something is materialized when that happens, that's when happens, happens. And it also turns out that this is how you get to see, there were so many cases when we worked together where some of handled, uninteresting, technical, super detailed, ended up this can of worms that you know, or this does rapid hole, or they brought together a whole flock of acts that we wanted to get shaving on. That's exactly what leads to creativity. So, or, to doing something completely new. From, you know, from the perspective of where you are say, you're here up somewhere up, it says, I need this to be done, but you're going to miss that perspective. You're gonna miss the perspective from which that little detail doesn't quite fit, right? You couldn't tell an interesting story about that. And when somebody has, goes there and looks at it and says, I can't really capture an interesting thing to say, or to show about this little detail, that's a sign that the story is wrong. The overall story is wrong. And then we stop and we look at it, and it has almost always been a source of the leap. Almost always. We didn't know it before it happened, but almost always it didn't happen. So now we are just blindly shaving all the acts we can see around.

Rein Henrichs:	So I, I remember when you started by saying that culture is formed or shaped or created from language, and I would, I would go, I would agree with that, but I would also go a step further. And I would say that culture is formed by storytelling. And in fact that a culture is a shared collection of stories because language words. So there's this old American pragmatist idea that words derive their meaning from their relationship to every other word. Then Maclntyre's idea is that words derive their meaning from being in stories, words, derive their meaning from the collection of stories that include them in a tradition. So I think that's why stories are so powerful because human beings are inherently storytelling creatures. Like one of MacIntyre's other ideas is that identity is really nothing more than an autobiography that we are forming, constructing constantly. Our identity is our, the story that we tell about ourselves.

Tudor Gîrba:	Exactly. So that's why it's so cool because when we get to externalize our thoughts into code that's, by the way, as close as we can get to materializing philosophy, you know, when we get to externalize our thoughts and we get somebody else to see the world in the same way as we do, this is such an amazing, it's such an amazing feeling there that's exhilarating, it's simply worth just hunting for that experience.

Jessica Kerr:	I think that's the magic in taking this idea about how we could look at our code and read our code from these different perspectives. And you can describe an idea like that in words, but it's fundamentally different to be able to build it and show it and experience it and the vendor. I'm sure you're familiar with the experience of frustration. If you got an idea in your head that you can't, you can't quite express, and it doesn't matter how much you, you know, you keep trying, sometimes the only way is going back and materializing that idea in code. And then there's this amazing satisfaction, this amazing magic that happens when someone else can see the world the same way we do with that level of precision of that dream, that was in her head. The beautiful thing.

Arty Starr:	We started out talking about shaping data individualization to give people a completely different view in software is like that, except in more dimensions because it's alive and interactive and completely changes how we see reality.

Rein Henrichs:	So I think I can take MacIntyre a step further here which is to say that a culture. So for McIntyre, a culture is basically synonymous with a community of practice. And the culture is defined by both a collection of stories that they share and a collection of practices, right? And so for MacIntyre, those stories are embodied in what he calls a collection of canonical texts. So for example, the Christian culture or tradition includes the Bible as a canonical text. And there are disagreements about the interpretation of the Bible, but there is shared agreement that the Bible is a thing worth interpreting, right? And so teams that write code come together around a shared agreement that the repository containing the code is a canonical text of their community of practice, right? So they may disagree about how to interpret the stories contained in the repository, but they agree that that is the thing that their community is about interpreting,

Arty Starr:	Okay, this is a lot it's time for reflections.

Rein Henrichs:	I was thinking about different perceptions of, or representations of the data of the code. And I was thinking, so you were talking a lot about reading code and that writing can be separate. But I think it's also possible for them to be the same. So in functional programming, there is a concept called a lens and I won't go into it cause we don't have time, but a lens is a first order, getter and setter. So if I have a point and a point has an X coordinate and a Y court, if I have a lens for X, I have a way to set X and get X for any point. So if I apply the lens to a point, I then get a setter and getter for X for that point. And there are some rules about lenses that make this well behaved. So for example, if I get a thing and then I set it back, I haven't changed the underlying data. And so when I think about ways to perceive data, if I think about them as lenses, that gives me a principled way to both have a new perspective on the code, but also to act on the code through that lens,

Arty Starr:	I'll hop back to the beginning. And there was one thing that you said really early today at the end of a presentation. If there's no question that makes you think that maybe you haven't moved anything that it's so important, we talk to each other to not know everything and to look for those surprises that come out of really listening. And then later you came back to the acts shaving, to the part of when you're not just implementing, when you're creating and the world you're creating speaks back to you with, well, that part doesn't make sense. If you look for those surprises and listen to them and you discover something new.

Jessica Kerr:	And there's two things that I've been thinking about putting together one, this idea of optimizing for happiness as a first principle, that everything goes around, that everything works around, looking at what has happened, you know, with this current crisis. And a lot of problems that have been there for a long time, the system being incentivized, driving certain ways, I feel like we've lost sight of some of these really fundamental things of what it is we're optimizing for, why we do any of these things we do. And this disruption is also an opportunity for us to go back and identify with those fundamental first principles are identify what it is we want to optimize for. And to really come back to these fundamental things about what are the stories that we're telling ourselves and creating in our culture and creating through our software. And if we could build a world where we were optimizing for happiness as a first principle, what would that look like? Can we create space for invention and dreaming and whatever sort of system support needs to exist, such that the whole world can start shifting to optimize for those sorts of things. I feel like to be able to do that. We have to get back to some of these fundamental things, some of these fundamental questions around what are we optimizing for? I think Tudor made a good point, If software is inherently really fun. I mean, it's already really fun being able to create and make stuff. And if the system is screwing that up, such that software, isn't fun when it's already fun, right. [chuckles]. We just kind of mess up the fun. It we could make software fun again. Maybe we could I say fun again. It, it is fun. It's just that we kind of snuff it out. I should say, [chuckles] if we could make the system work harmoniously with the having fun with our happiness. And I feel like there's a whole lot of need right now for innovation and it's important for all of us to create and support and try and find ways to enable those things as opposed to kind of tearing it down. And snuffing it out because it is hard to go outside the box. You know, it's hard to present ideas and not be understood. And so a lot of times people don't because it's hard. So I'm thinking about like, how do we do more of that? How do we move that direction?

Tudor Gîrba:	First? I'd like to thank you very much for this conversation. It was really exciting. But then I realized, well, this was supposed to be a panel, I did most of the talking and that emphasizes how I was not doing a lot of the listening.

Arty Starr:	But, you are the guest Tudor. You're supposed to talk more than the rest of us combined.

Tudor Gîrba:	Still there's an interesting point here as to which ideas are worth leaning into and which ideas have priorities. Is there something like that? And I think with software, we are forcing people to listen to our ideas. Software is our, is a material tissues of our thoughts. We are reshaping that the whole world, although this software, and as a consequence, we are forcing other people to listen and then to act according to our thoughts. And there's a great responsibility that comes with it. And it just goes to show, as I said, at the beginning, that I'm training, I think that this skill of storytelling is a, is something that can be trained. And I think that we have to train that skill in both ways, not only on the one with which we express something, but also the skill with which we read or we understand what somebody else has expressed. And I think we have to understand our privilege and we should also live up to the responsibility that comes with it.

Rein Henrichs:	Alright, that's a wrap, but I have another thought so you can all leave, but I'm going to say it.

	[Laughs]

Tudor Gîrba:	I can stay.

	[Laughs].

Arty Starr:	OK, you all can stay. I'm going to say for the recording. Thank you for listening to Greater then code episode. 193, please support us our page is Patrion.com/Greaterthancode.

Rein Henrichs:	Okay. So the thought was we can start our identities by telling stories about ourselves, but we, we don't create them de Novo. We create them by drawing from the shared stories of our culture. But also that means that representation is important in part, because we derive our sense of belonging in a culture, in a community by seeing ourselves represented in its stories.

Tudor Gîrba:	Exactly. There's another point that, that I look. Unhappy people are unlikely to create empty solutions. That's why developers happiness matters, right? Like we see with politicians like their frustrations, then they end up influencing all, all the bad moves that governs the whole country. And that's a terrible thing. Like small group of people who can get to influence everybody else at this whole, whole new level. Right? Yeah. That's, that's why I think, yeah, it's really, it's really important. So one of the points that you mentioned, you put with the lenses some of the lenses can be edited, but some of the lenses will only be interesting from a reading perspective. Absolutely agreed. Right? So for example, this is what you see with the idea of projectional editors, where are the same, same thing. Like you can interact with it multiple ways and ends up creating the same infrastructure behind it, same tree. And then you can see, but then we should never limit our sense of, for example, a lot of 
our understanding, or a lot of our focus is not on the code. Like practically, when you were saying, I create here the scene. And then I see, I see the rendering of it here. Here this is code, this is an instance, this is the code running. So here, this visualization is of an instance of one object that can potentially be instantiate over that code. And so there's this super interesting things that are happening. The same thing happens with debugging, with logging or security, all of these things that are like orthogonal to how the code might look like they are equally exciting. And those it's not something you're going to edit, so.

Rein Henrichs:	So, not all getters can have a compatible center, right? So like the example of the spreadsheet and the bar chart, I can't drag the bar chart around. Right. Cause it's, it's a lossy, you know, it's an, it's an average or something and it's lost, you know, there's no connection back to the data, right? The example I gave of a point and like the X coordinate is sort of a digging into the data, but there's another way you can use lenses. That is, I think, transformative, which is I can have a lens for a point that is the polar coordinate lens.

Tudor Gîrba:	Yes, exactly.

Rein Henrichs:	Now I'm not just digging into the point. I'm changing the way I perceive.

Tudor Gîrba:	Yes. Exactly.

Rein Henrichs:	And interact with the point. So I can set the angle and set the distance and that changes X and Y. So if I want to rotate a point by 90 degrees, I can either do all those calculations or I can say over the polar coordinate lens, add 90 degrees to the angle. And that just does the right thing.

Tudor Gîrba:	Absolutely.

Rein Henrichs:	And the way you get that to work is the lenses. There has to be a relationship between the getter and setter that makes them well behaved. So there are certain laws that relate the behavior of the getter to the behavior of the setter. So the polar coordinate lens is a isomorphism, which means that there is an information by directional information, preserving transformation, right. And the laws for the, for the lender things like if I get a thing and then I set it back, that's the identity. I haven't changed the data. Another one is if I set a thing and then I get it back, I get what I set. Right. So if you have those properties, if you have those rules, then you know that the lens, the bi-directional lens that you've made is well behaved. And you don't have to worry about whether you're maintaining invariants because abiding by the rules means that it already does. Anyway, this was super fun. And I'm really glad we got a chance to.

Arty Starr:	Yeah me too.

Tudor Girba:	Thank you very much.