Hello, everyone. My name is Mihaela Guitarsa. Happy to be with you here today. Thank you to the organizers for giving me the opportunity to share what I love and what I've learned into my experiences and challenges that I had along the way. At my core, I'm an engineer and I also like, even though it seems being an engineer and someone that does some public speaking, it's not really going together, but I really like to do this and Besides my interest in software and technology, I like to research and prepare content that I gather from my experiences or from things that I would have liked to know at some point. And I didn't have anyone to tell me. And I wrapped this in my presentation and, opened the conversation in events like this one today. So thank you to the organizers for having me again. And. I hope that we have a beautiful conversation or that I at least challenge you a bit to go outside of your, your area of looking at things. Why I'm saying this because today's conversation, it's going into the area of Not so much technicalities, but the way we are looking at the problems and challenges that we encounter every day, the way that we organize our work, the way we think about ourselves as developers, I'm trying to open the conversation about how we are interacting with, with our work and with our challenges on, on a daily basis. So I want to open the conversation with a little exercise, an imagination exercise, basically. Think that you're standing at the base of a towering skyscraper and you marvel at its intrinsic design, right? Every element in the structure, it was meticulously planned. Each element is serving a purpose in the overall structure. Now let's think about the architect who designed that. How they had to envision all those interactions. How their building is going to stand We stand the test of time and face storms and all sorts of challenges, serve its occupants, how everything was so purposeful thought of in order to have the best structure in the end. So starting with this mindset, we can transform the way we are building software. Taking this kind of concepts from another field encourages us to think beyond the immediate, to consider the long term impact of our decisions, and to create systems that are not just functional, but resilient, and scalable, and enduring. I want to for your attention. tasks to stay with this analogy in our mind. We are not just coding, we are building something of a digital skyscraper. Let's explore how we can build them with the same level of care, creativity, and foresight. Because as programmers, we often find it challenging to step back and see our products like we are looking at a building, right? Most of the time we are deeply engrossed in our tasks, and unlike physical construction, we don't have the same boundaries, very strict, very exact boundaries, right? Software development does not have the same limitations. We have freedom and we have flexibility to push these boundaries, actually push the boundaries of what's possible in the end. So despite this freedom, when we discuss perspective and way of thinking, we tend to stick to familiar patterns, rules, and we rarely venture outside the box. And even when we do, We may not really embrace new ways of thinking, we feel comfortable to stick to our existing beliefs, but by breaking the cycle through reflection. We can adopt the growth mindset that leads to better decisions and a more fulfilling work experience. And mindset in this case refers to attitudes and beliefs that shape the way we approach work, the way we solve problems, the way we tackle challenges. It's the lens through which we view our abilities, tasks, and potential for work, and the way we actually face challenges. Brace for impact when difficult situations appear and when we're discussing mindset, we cannot stop, we cannot avoid stopping actually and looking at ourselves. And if you've ever thought, okay, I'm just not good at algorithms. I'll never understand this framework. Instead of, I don't understand this yet, but I can figure it out. You are tapping into fixed mindset. Because this perspective limits your growth. It creates a mental barrier to learning and adaptation. Developers with a fixed mindset shy away from challenges, fearing that failure will expose their limitations. In contrast, a growth mindset is the belief that abilities and intelligence can be developed through dedication, learning, hard work. People with a growth mindset embrace challenges and view failures as opportunities to learn. So we need to be very honest with ourselves and see exactly where we are. And I'm not asking you right now to tell me, okay, what, where are you, where do you find yourself more, but more like I want you to be honest with yourself. Because in the end, the scope of this discussion is to set a starting point for growth. And since we're discussing about starting point, I think it's a good thing to bring to discussion a story. And I heard a while ago, I think I was, I don't know, doing some volunteering and someone told me, so I don't know who is the author, whoever is, copyrights to you, credits to you. But the story goes like this. There were some people on the breaking stones. And then there is this man that was going towards the hill and he got curious and asked one of the people, okay. What are you doing? And that person was very focused on the artwork. And they were bothered by the question. No, they didn't like to be disturbed from their work because they were very dedicated. And yet he answered and said, I am breaking stones. The man got very curious and he went to another and to another until at some point he got a different response. Because this last person that he asked told him, I am building a castle. As developers we grow new faces, right? Sometimes we simply complete tasks and we are just so focused in that area that we complete the entire context. So we are breaking stones. Okay. On other times, we are interesting in understanding the system and going beyond the task and trying to understand the business, maybe very dedicated, trying to improve and so on, which is like building castles, right? There are many reasons this imbalance happens. Sometimes it's the organizations where we are working. Sometimes it's the limitation to information, to the right information. Lack of options, fear, burnout, not caring about a project. this is a reality that we have to be honest about. Or maybe we're just the right, the wrong person for the job. this happens. But I feel that we are so impacted by outside factors and we are so overwhelmed with it. Checking some sort of what is the image of the great developer at some point, like we have that thing with the effective developer or efficient developer. Should I be an effective developer, one that takes time to ensure code is clean and scalable and documented, or should I be an efficient developer that I implement, I loadbox, I deploy, I, this approach allows me a faster time to market. And, I'll just focus on speed, skip this part with extended documentation and meetings and so on. We are trying to comply with some patterns, but sometimes we have to look at ourselves as professional despite the context in which we are at some point. So add our skills. And again, I dare you to be honest and use the circle of competence to understand what are your strengths, your limits and expertise. Using this mental model in the end, it's about focusing on what you know well and recognizing where your knowledge gaps are. And in this way, you can work effectively with your expertise while expanding it over time. So we can start from the inside circle, right? Identifying that. Seeing what are your strengths, what technologies, languages, patterns, you truly understand at a deep level. Be honest about your limits. Stay focused on your areas of expertise while delivering on current projects because this allows you to build confidently and produce high quality work. When presented with tasks outside your circle, collaborate with others, whose strengths complement yours. People that inspire and you can learn from. While you're going outside in the circle, outside of your, the stuff you know, identify knowledge gaps or areas of interest that you want to grow into. Set clear goals. practice. Take on projects that stretch just outside your circle but are manageable with effort. Of course, we're going in through this process, we're having this process, taking into consideration. Helps you avoid a situation of overextending your, and having overconfidence, because you must be cautious about assuming you're skilled in areas just because you've been working at some point with something similar. And there is this cognitive bias, the Dunning Kruger effect, where it is demonstrated by this psychologist, a true series of experiments that People with low ability or knowledge in a specific area tend to overestimate their skills, while others with higher ability often underestimate their skills, right? So this keeps a balance for you to know exactly where you are and don't overextend. I'm sure that each of you had a situation at some point where you had to deal with someone that was having this bias and you were just so you know, maybe pissed about the fact that they are being so confident when you know exactly how things should be. So don't be that person. On another part, there is this mental barrier that we need to be careful about. Because even if we don't realize, this is something that is very powerful and limiting at the same time. Because, let's say, if you identify as a NET developer, you are a NET developer. You are stuck. Right? in your mind, you are a NET, or Java, or whatever. It doesn't matter. You are an ex developer. But if you are identifying as a developer who is using X, it can be NET, Java, whatever, you suddenly can be a programmer that knows and can learn and can try other things too. Just think of situations where you, maybe someone in your company and said, okay, we don't have a project right now that it's using the skills that you have. But look, there is this opening in here, something that we think that might be interesting to you. technologies are going to evolve, so try to not. identify with them, try to keep your mindset fluid in this area and don't block yourself into a, a bubble. The circle of competence isn't just about recognizing your skill, it's a tool for growth in the end. When you understand where you excel and where you need to improve, you can make better decisions, you can work on yourself constantly and become not efficient or effective or, all sorts of labels. But be a developer that is bringing some impact in your work. We've been discussing about the inner circle, and we've been discussing about that, circle where we know what we don't know and we want to grow. But we also touched the areas where we think we know something, but we actually don't know. But how about that outside circle, the thing that we don't know that we don't know? How do we tap into that area? that area that I think that is the area of blind spots, It's difficult to understand the system we're a part of precisely because there are blind spots. We can't see what we are looking for. We only see them at some point where we have, we have somebody porting from production or something like this. And a way to do this, I found, of course, a lot of the conversation that we are having today has a lot of points from the book, that can be found also in the book, but. This precisely got my attention because these are three things that if we work with are going to help us see the blind spots that we have, to reveal those blind spots and, at least minimize that area if not completely, reveal it. be that, of course, we are discussing, I was mentioning the book, which is the great mental models by sheen purge. And in the book, we have this three, factors, perspective, ego induced denial and distance from the consequences. We need to approach problems with different perspectives, even if it goes on different models, mental frameworks. We are going to discuss today some mental models and some example of mental models. So this is one area where we need to expand our knowledge. Then we need to lay low on the ego and be honest and ask for help and accept that we are continuous students. And we need to face and stay close to the consequences of our decisions. When we are making decisions that we are not. Assuming the consequences were, we create that broken window effect, just as an urban environments where one broken window left unrepaired signals lack of care and invites more damage. So also in our work, small RSO issues in our code. our mindset, our processes can accumulate, leading to bigger problems over time. If we don't address these issues as early as possible, we risk letting all sorts of poor practices and blind spots take root. So it becomes harder and harder to solve problems. And going further in the perspective part, because this is maybe the most powerful of them. You know how in school we are learning. are learning about different areas, right? We are learning about physics and biology and math and all psychology, economics and so on. And we are, we've been learning and creating this way of thinking in departments, right? But in the real world, we need to combine these departments because problems in the real world are not Divide it so precisely, right? So we need to work on our multidisciplinary mindset, because if we don't, we miss the full picture of a problem. And our next step is not going to be the, the closest to the best, if not the best. If a single worldview dominates our thinking, we'll try to explain every problem through that lens, even if it's not the right fit. the old saying with, to the man with only hammer, everything looks like a nail, but not. It's not like this in this, in this world. We need to understand the complexity of the world and we need to understand how important it is to, draw knowledge from, from different models and different perspectives and different fields. In an example, and actually the first mental model that I would like us to discuss today is the Swiss army knife approach, which is Charlie Munger's way of thinking, Charlie Munger's way of thinking. Basically, he believed in having wide, a wide range of mental models, similar to having many tools. as we have in a Swiss army knife. And these metal models, of course, come from different fields, from different perspectives, and they help us see challenges from different approaches, approach them from different angles, to find the best solutions. And if we think, if we go into a forest, with a botanist, real estate agent and a yoga trainer, of course, each of them is going to see a different perspective. Maybe the audience is going to be marveled by the nature, right? Exactly. How about details from the nature and, appreciate it and think about how we can, we need to keep this as untouched by human, action as possible and so on. A real estate agent may be thinking more from the perspective of a business, right? How he could sell this, how, this could be a very good place for having a, a building, a neighborhood and so on. Then the yoga trainer might be thinking about the energy and what is happening in their house session would be so useful to have in there and to really let our bodies and mind to use the energy from there in order to have a great experience. Each of these perspectives captures a part, but not the whole picture. And if we rely on a specific discipline, we develop gaps. Yeah, those blind spots that we were talking about. You can add up, of course, there is a confirmation bias, which makes things even worse. Next, a mental model that challenges to look a bit at how we are considering, the materials that we are using or the way that we are organizing our work is the map is not a territory. That refers to the idea that abstractions like, diagrams and some schemes, that we are doing. Yeah. or any representation are not the same as the reality itself. So any model or map that we create to understand something is a simplification and doesn't capture every detail of real world system. And this applies directly to software development where we work with diagrams, for example, and requirements and models that not fully represent the complexity of the system itself. And we can think, for example, Let's say we are, a very careful developer, that follows, the project specification, document closely, but then when testing in production and, having our solution in the real world, we encounter some unexpected issues, right? So using this model helps us recognize that the specification. The document, the map, yeah, it's not the same as the actual running system, the territory. No matter how detailed the specification is, it will miss some real world behaviors or edge cases. And by acknowledging this, we remain cautious. We implement retesting, including those edge cases that we were mentioning, to ensure that the actual software performs as intended in the real world. The third mental model that I want us to touch today, it's the second order thinking. And I would like to start by there is this effect, all the cobra effect. Basically, the story goes that when the British colonial government in Delhi wanted to reduce the number of cobras in the city, they offered a bounty for every dead cobra. Initially, this seemed like a good idea, but in time, there were some individuals that realized that they could breed cobras and they'll kill them for the bounty, right? And increasing, of course, their profits. This was not a good idea since the government found out and stopped the program. Yeah. After discovered this unintended consequence of, of their program. And in response, the cobra breeders, of course, having no use for the snakes, they released them causing the cobra population be even worse than before. So this unintended outcome is recognized as the cobra effect. And actually this is, if we look carefully, we see the consequence and the consequence of our decisions in the. consequences of the consequences of our decisions. And this is exactly what the second order thinking mental model touches, because it encourages us to look beyond the immediate consequences, to understand their long term effects, as well as ripple effects that might arise from these decisions. And let's again take an example in software development. Let's say that we are part of a team that is being assigned to work with, e commerce platform, And of course, The thing that we do, we are focusing on delivering the, the core functionality of the platform. Ensuring that the basic features like, think first, right? Basic features like product search, checkout, payment, work smoothly, right? Maybe we even think about, okay, let's prioritize performance and speed to give users a bra, fast browsing experience. This is the first thing that we are considering, when we are here in e commerce. Okay, but these are the first order thinking. This is an example, again, take it with a grain of salt. But if we go a bit more into details, we can actually consider those second order effects. Yeah, we can start thinking beyond the immediate functional requirements and think, okay, but what happens if spikes? if traffic spikes dramatically. Yeah. What happens if part of the system fails, for example, the payment component. And if I have to add new features, features to this, will it be easy? Will it be hard for the business to evolve? How things will be? By asking this kind of question. So going a bit beyond to the second order concerns, we can see other important factors. a service like scalability, the need for availability and fault tolerance, performance under load, security and compliance, and so on. this, this mental model helps us exercise, considering the ripple effects of our decisions, and help us identify and prioritize Characteristics that will ensure long term success, right? It prevents us from focusing on short term functional goals and, helps us handle future challenges and opportunities with minimal, disruptions. an interesting part about, about us, and we are discussing before, about this when talking. about blind spots is that we cannot understand a system that we are a part of. And relativity involves understanding that things are not absolute and often depend on context or perspective. Yeah. So my all time favorite example or situation for this is when we have to choose from or technology language and application for an application. Doesn't matter technology language approach. Doesn't matter. I remember some years ago, we were not sure if this dispute since still is, but there is what is best. Java, what is best. React or Angular, which is the best, has the best approach, how we are going to work with it. things like this, like what has the most advantages, which one is the best, where? Instead of asking what's the best programming language, how about, I think, what is the best programming language for this specific project? The best language is relative to the skill set of the team, projects, requirements, timeframe. There's no absolute best answer. What matters is the context in which the decision is made. Then, instead of always striving for brilliance or perfection, it's often more effective to focus on avoiding mistakes. In the context of software, for example, this could mean focusing on common pitfalls and making sure to avoid them. For example, let's say that you have a deadline, a very aggressive deadline, you did not expect this. Things have changed in the project. What we are going to do, instead of thinking, okay, what are the best practices to follow to meet this deadline, those, magazines that are then giving you, 10 steps to be the best manager, 10 steps to be a productive developer, and so on. Instead of looking for these 10 steps to ensure that we meet the deadline, how about we apply inversion, right? And ask what common mistakes we need to avoid that could make us miss the deadline? What did we do the last time when we missed the deadline? Let's avoid doing that. Start from that point. Then, by deliberately avoiding these common mistakes, you increase the chances of success rather than just looking for the best way to do it without being validated. You already validated what are the worst, the worst things that you can do to not be the deadline for sure in the past. Start from there. Focus on ensuring that simple errors don't derail the project. Then moving forward, you know how we have this tendency of Thinking that the more complicated something or the problem that you're facing, or the more complicated the solution that we are giving you, the more complex, the more, important we are because we don't know the same thing as everyone else. So we end up becoming really good at something specific just to stand out. And sometimes we actually find or look for complex, resolutions for our problems just to make sure that others can easily understand it. But besides that, to make sure that we stand out with our complex way of looking at things, our outcomes raiser. It's a concept that suggests that when faced with multiple competing solutions, the best starting point is to start with the simplest one. If your project is not, explicitly asking for the most complex solution, start with, with the simplest one. And we have a lot of examples in software. I'm sure that you've been thinking about at least three since I opened the conversation about this. But what I can say to wrap up this is to avoid overengineering solutions in both development, design, architecture, design for simplicity and usability and focus on straightforward solution during debugging and problem solving. And, a simple, more focused approach is easier to use and it's easier to build upon. of course, again, take it with a grain of salt. Check the context of your. situation, problem, whatever it is, and try to build step by step. to see exactly what kind of approach you need to do, but don't respond out of ego, which we're mentioning a bit before. Of course, we've touched today some mental models and there are a lot of mental models. I actually encourage you to look on it and see, but it's not about knowing them, knowing as many as possible. It's about being open and learning. Yeah. We need to. move away from solving immediate tasks and start thinking holistically about the systems we build. And these kind of models help us navigate complexity and make better decisions. And they allow us to design software that does not only solve current problems, but is adaptable for future growth and change. So I'm going to leave you with this beautiful code from Alexander, which I think it's the essence of a developer's mindset. When you build a thing, you cannot merely build that thing in isolation. You must repair the world around it. understanding that every piece of software contributes to a larger system. So just to close the circle, build castles. Don't just break castles. Don't just break stones. Think about your, your work from this perspective. I want to very much for staying with me today and for listening to my talk. I hope that I was able to. to open some question for you or some areas that you would like to explore further and yeah, reach out and let's discuss. Thank you very much.