 Hello everyone. So my name is Tripad. So I'll be, you know, speaking about abstractions. I work as an engineering manager at Deserve Labs in Pune. So we are a fintech company offering credit card as a service platform. I am quite active on Twitter. So you can reach me out on Twitter. And I do have some interesting discussions on Twitter as well. And that's, and during those interactions, some of this idea about abstraction came about. So one of the nicest podcast that I generally listen to is called Econ Talk. And one of the speakers of that was Helen Leitman. And he made a very interesting statement that all science is provisional. So all laws, nature, law of nature discovered by scientists are provisional. Scientists will never know whether they have reached the nirvana or the ultimate law that governs everything else because, and that's the nature of science. And that's how I started some thinking when I started thinking about how if we can use these things in our work as well as, you know, apply in our area of work. So I would like to, and part of that problem, I used to work as a consultant for one of the scientific publishing companies in Pune. So those guys were, you know, some of them were like crystallographers. So what they used to do was, you know, scatter x-rays on some crystals, which is opaque. And you can, you know, see a diffraction pattern on an extra plate. And then you figure out how the structure of the material is. And that's how you discover and, you know, make a system. But the problem with this approach is that for n number of combinations, you will have the same scatter pattern on the extra plate. And that's actually kind of intrigued me because what you see on the extra pattern on the photographic plate is the result of that arrangement. You don't actually know the arrangement. You're trying to guess that arrangement by, you know, putting or scattering x-rays on it. And the way they got around is they know few patterns produce this kind of scatter or this kind of arrangements produce this kind of scatter. And you look at the extra plate and then you guess what kind of arrangement, internal arrangement of atoms and molecules would be there in that, you know, subject under study. And that's kind of inverse problem. So what inverse problem says is that we know the outcome. We have observations and then from that we're trying to figure out what actually lead to that particular outcome. And that is part, so there's a saying that it's easy to engineer, but it's very difficult to reverse engineer. And that is a major theme that I discovered when we talk to business scenarios or business stakeholders and they describe something and then we get something from it. And that is, so if you look at, so I was thinking about, you know, inverse problem in, you know, what are the interesting inverse problems that we see around us. So StoneJ, I mean, archaeology is the nicest of the lot I can think of when you look at the outcome of things that has been done or a result of things that have been done. So if you look at Stonehenge, you know, you see the structure, but you don't know how it was done, why it was done, who did it, where, I mean, what were the methods. And that is how you tend to see, so you in our work in software, what happens is we, somebody tells us, hey, I want this, I want Stonehenge, Stonehenge, for example, or I want a search. And they don't describe how it is to be done, what are the inner components, what are the interactions between those components. And deciding that is always challenging. And challenging in a very, very, not just in terms of engineering way or difficulty way, but even, you know, there are a lot of unknowns and that's where the challenges are, of course. And the challenges are also opportunities where we have unknowns. Part of this challenge is, if you describe the end goal, what you're missing is the intermediate state of how those systems are being built or should be built, or how do you think about intermediate state. In complex system, there's a term called as stable intermediate form, right? So basically what it means is if you want to build a bridge, bridge cannot be built or a building cannot be built in its final structure from the start. You have to have a lot of scaffolding to support it, to, you know, manipulate it and get it in a way, but once the building is finished, you don't see the scaffolding. And that actually adds a level of complexity to the problem, because if you look at the stone, if you look at the stone hinge picture, you'll see all the scaffolding missing. I'm pretty sure they must have used some scaffolding, but how they did it, all of that, that kind of data is all missing. And that is where this inverse problem is far more trickier, because you are missing the whole journey of how this thing was built or should be built. Okay. And another case, very classic case, what we've always known as survivorship bias is the case of missing observations. So, if I look at a finished outcome, or if I describe a finished scenario, the things which are not apparent are not present in that scenario are missing. So, and that is where it biases you in certain dimensions. And that is where I hopped into a few other things. What happens if I don't see something? So, this is a classic case, this is a black and white picture, and there's a grid overlay on top of that black and white picture, and our eyes actually start filling in the information. So, based on the context, of course, so we know something to be looking in a particular way, then we start extrapolating what we have seen, and which is not there. And this is a very subtle point, and sometimes you call it experience, sometimes it's called mistakes, whatever it is. And that is where I come to my next point of unlock the lock. And that the point I'm trying to make here is that can we figure out what are the assumptions I'm going to put unknowingly, knowingly or unknowingly in the model that I'm trying to build or software I'm trying to build. So, if you look at the lock, I mean, fundamentally, the statement was very intriguing to me when I heard it first. A lock is a lock because of the key. If you don't have a key to the lock, lock is nothing but a dead weight. And if you look at Etsy or certain sites like that, people have put on those items as artifacts, as dead weights, and they actually eliminate a certain dimension of the lock which is hidden from us. So, that is how we look at. And we always think when I describe a lock, it's always in conjunction with a key. But if I don't have a key, it's already hidden from us, right? I mean, it's imagined we add that as key as a abstraction, and then we design around it. So, typically, if you look at a lock as a method, then you'll always see those things. And that is where I come to my next point of in an action of abstraction and context. So, we are always designing abstraction in pair. So, one pair is the context in which we are designing those abstractions. And that context is subconscious or assumed or imagined or there are assumptions that we explicitly or implicitly make around to design those abstractions. Thus, what we can say is that abstraction is nothing but interaction between two components of the coupling. So, only the pair or the coupling of your context and the thing that you are trying to model and make it physical. So, or realizing software maybe. So, the only part of the artifact that is visible is your software or interpretation or assumptions are hidden from you. So, when you look at a lock, if I just show a lock to someone and don't show them the key, they'll obviously add key as a concept to it. I mean, a lock, without a key, should not have a lock or unlock method because those are useless methods or useless functionalities to have on that artifact. But if I describe it as a lock, we put in all of the assumptions on that particular artifact and say, oh, this should be the behavior that should be the behavior or those are assumed behaviors. And those are may or may not be there and can be used or are added by us. And that is where, I mean, you know, the case of our story of elephants and of six blind men. So, and that is where the context matters much more. See, if you are dealing with a very large problem, your abstraction will depend on the kind of narrow focus areas that you're looking at, although we make fun of it, but that is the reality. I mean, this is the reality. People will focus on narrow particular areas and then they come up with the suitable abstraction for that particular narrow areas, adding in all the surrounding assumptions. And that is where I say abstraction is provisional. So if you look at my first slide, science is provisional, and that is where I just got some inspiration from Alan to say that, oh, maybe abstraction is also provisional. So abstraction can also depend on the context. Again, context is nothing but our experiences. So it depends on what we have seen, trade, experience, yada, yada, I mean, mistakes we have made in the past, so on and so forth. I mean, sometimes we call it experience and sometimes we call it mistakes. So as we experience more of that domain, so if you go back, as we see more of this problem, we start realizing more, we start refining our abstractions more and more. So the more wider area of our context, the abstraction can become different, refined or course. So which means that abstraction designed for a particular context should also change when the context changes. So it's not a stable thing saying, oh, this is perfect or that is perfect. What defines a good abstraction is how suitable or how fit it is for particular context and not nothing beyond that. So if you, I mean, this is a famous quote by Maya Angelou, is your sum total of everything you have seen, heard, smelled, being told, forgot, it's all there. Everything influences each of us and because of that, I need to be, I mean, we try to be a positive person as much as we can. But that assumes experience is a set. I mean, what I'm trying to say here is that, no, it's a list. The order in which you experience things, changes your outlook, changes your context and changes your way of analyzing particular things. So Nassim Thala was a very nicer quote on history is to say, if you want to become a philosopher king, it's much better to start as a king than a philosopher. Because these two outcomes are vastly different and sometimes they are referred to as non-ergodic systems. So non-ergodicity is where your experience matters, your history matters. And that is where I come to, so I used to run bootcamps, I still do sometimes. The outcome that I've seen, I mean, it's a simple game of snakes and ladders. So that what happens in those games is the moment I define it as snakes and ladders, there is always preconceived notion of what a particular thing should look like. And if I start playing around with those concepts, people get, I got a very different way of different code bases that I ran with the same problem statement in different orders. So that is where how I pose it that if you change the order in which I add problem statement, your outcome or the final design would be different. For example, if I add snakes and no ladders for a single player game, your design, I've seen those experience, I've seen those designs being very different from, let's say, adding a snake and a ladder and then adding variety of rules. Or maybe adding variety of, you know, variety of different rules of dices like different dices or different snakes. So that is very related to the concept of ergodicity where history matters. So what you see and what you experience and what your outcome at particular previous event actually, you know, changes how you see things going forward. And that influences how you can design going forward. So and that is something called as part dependence. So abstraction is also very, very part dependent. So where you are will define where you can go next. And that is not absolute. So and that depends on lot on the context on sometimes even on chance. It's not like for the same set of problems, you'll always have same outcome. Right. So, I mean, I'll close my talk, I mean, quickly, and then we can have some time for question and answer is asking for ideal abstraction is asking for average abstraction. So on average, how does this abstraction look like? So there's no ideal abstraction. It's always dependent on your scenarios on your context in the order which you actually, you know, get those problem statements. Lot of it is not absolute. So it's all a variable and relative in that sense. And the next statement is basically to find right abstraction, just make a guess as to what it is. And if it exhibits the right property for that context, just stop and don't try and attend the perfection from that angle. Right. So there is no perfect abstraction that is, that is a suitable affection for a particular context. And that context changes, the abstraction should also change. And the kind of experiences, the order in which you get requirement will also evaluate or influence your abstraction is the thing that I wanted to discuss. I mean, talk about, I hope in the short time that I got, I'm able to convey some of these ideas and I'll stop here now. And then I take few questions if people have any. Thank you for joining us today. Thank you for sharing your experience.