Are you an SRE, a developer, a quality engineer who wants to tackle the challenge of improving reliability in your DevOps? You can enable your DevOps for reliability with chaos native. Create your free account at Chaos native Litmus Cloud everyone, thank you for joining my session. My name is Mitzvinik and I'm a developer advocate on the Facebook open source team. Today I'll be talking about legacy systems and how to fix them. So let's go. Alright, as I said before, today's presentation is about legacy systems or as I call things, session fixing broken Windows code team and you. So let's get started. So what do I do quickly about myself? As I mentioned, I'm an open source developer advocate. I work with an open source team where we are empowering diverse communities through open source technology. You can learn more about us at opensource facebook.com. I in particular focus on mobile open source projects like React native, lethal for building UI frameworks for Android, image library, image management library called Fresco or Flipper for mobile debugging and many more other projects. And obviously I am passionate about open source and contributing back to the community. Hence I'm giving this talk today and what's our focus today? From the title alone, it doesn't make much sense. And here I'd like to explain that. We'll talk about legacy systems, what these are, why we have them, how to deal with them and when to even work on them at all. I'll talk about union engineering and quality, why hybrid engineering has been so important to legacy systems developments. And just going beyond code, I'll talk about teams and about you as an engineer, as an individual, part of the team. All right. What goes into building software? Building software, it's code. Obviously it's the team that's working on the code. It can be your team, it can be open source community, but also individuals. Teams are consisted of individuals and we should never forget about it. And these human component, it all means that human component is essential. It's not just code. We can't view it. Trying to be objective, completely objective here. And forget about human component. We can't, especially when we're talking about legacy code. So making it very personal. Instead of saying building software, let's talk about building your software, your project, your application. And so building your code with your team and with you yourself. How many elements is that? It's three elements. And what can go wrong? Right. With your three elements in play, lots of things can go wrong really quickly. But before going further, I really want to step back and talk about title for a second, I said fixing broken windows. What are those broken windows? Why am I even talking about them in relation to the legacy systems? So broken window theory is that you're trying to focus and never forget about small things as part of the big systems in case of the criminal code as it was initially created for. If it's a nice neighbourhood with nothing wrong there, and let's say someone broke a window in a house, and if that window is not fixed, later on you will see other windows being broken, maybe some graffiti appearing and other things happening in the neighborhood. So the important thing is, was soon as you see something's broken, something cracked, you have to fix it. And that's why this theory is so important to us, because legacy systems, they begin to deteriorate the entire system, the entire application, entire organizations. And that's why we're talking about this today as if it was a broken theory applied to software. So why does it matter though? Broken windows was, I said, can lead to broken software. And broken software is broken code. It's broken teams and it's broken you because you're working on that broken software. And that's what the focus is for today. Broken software in its elements. Fixing these broken windows of software is where our focus will be today. And that will ultimately set our agenda for today. Broken code. Then we'll talk about broken teams and then we will talk about broken individuals and how basically it affects us as developers, project managers, managers, et cetera. So what's number one? Software grievance that we all can come up with. Often people would bring up legacy systems. Legacy code, if you were to define it, is simply code without tests. And I really like this quote because it's coming from Michael Feathers, who's an authority in this space. He's written a great book about the topic. And if I wanted to, let's say, more tests to existing legacy systems, can I do that? Can I make it non legacy by just adding tests? It's a catch 22. Meaning to add tests, you have to refactor your code. More often than not, the legacy applications you have in place are not easily testable. What it leads to. To refactor you need tests because you don't want to regress your application, because you added some automation around your application. And that's why we can't just add tests because we need to preserve the behavior. Nobody cares that you are changing these feature. Your users ultimately want the same behave that they used to. These don't care that you might have moved the button slightly they care that they're still able to log in, don't care about the requirements, they care about the live product, the production product that they interacting with. So you behave to switch your focus from just being an engineer and becoming a user and trying to comprehend where your focus should be. And that's why customers care about behavior. First is what you have to keep in mind throughout this application, throughout this presentation. So do we just leave the legacy systems? Since there is a catch 22, you can change them. You can add tests because you can't refactoring them. And I would obviously say, I want to say no, but I can't. It's maybe, or as any contractor would say, it depends. You should always keep in mind cost of transition, return on investment. Does it worth these effort of adding tests and refactoring? Maybe the system is working. If it's not broken, why would you fix it? Popularity contest is what you want to avoid. A new test framework comes up or a new program framework comes up. You don't want to just refactor the whole thing. It's waste of money most often than not. And you always have to keep in mind nothing is an option. Meaning that when you evaluate changing something in your application, you always should have an option for let's do nothing. Can we actually do nothing and compare it against other options? So what if we want to change the code? What if we want to fix the legacy systems, our broken windows? What does it actually mean, changing the code? And don't forget we are talking about code at this part of the presentation. Changing the code means working on new features, bug fixes. It can be design changes or optimizations. And so if you're changing legacy systems, it's time to change its legacy status. You don't want to have it as legacy as not tests code. And that's where I'll bring up the main rules of legacy. What exactly is legacy code? I gave you one definition, but there is more to it than just no tests. You have to keep in mind these chia pet pattern, basically making sure you don't have these inline code changes to your legacy or like appending to the existing software just to make it testable. That won't work. You have to avoid glued patterns, meaning things like singletones, very non thread safe way of writing software. It has to be avoided because you can't really easily test it, meaning it's going to be legacy. You behave to keep single goal changes in mind, making a massive pull requests with lots of different changes in that one pr not going to get you far. And that's why those changes to the legacy has to happen incrementally. And don't forget, best is not always the best. You sometimes have to go for the better. So even if you can't make an ideal application by rewriting the whole legacy that you had before, maybe you can go for just changing a small part of it and making a big difference. Optimize your overall app. Don't try to move the mountains if you can just move your house so much slightly. And so the general guidance when dealing with software with legacy systems is identify sims or as they basically called, unit of behaviors. It's the parts of your software that actually responsible for the things that your users interact with. Keep in mind the solid pattern. That's a single responsibility principle, open principle, and many other ones you can find fairly easily from this acronym and just keep piling up things in your toolbox. Ways to deal with legacy maybe you can delegate. Delegation is a great pattern or builder patterns for legacy systems. Just make sure you increase your toolbox as you progress in your career. What if it's not just legacy? The same general rules apply. Like if you're trying to improve your software that you can just call something very old, something untested. The same principles that I've just highlighted, same rules will apply anywhere. They will improve any part of application you're working with. And so what people would usually call code smells, it's actually broken windows. Code smells is basically duplications in your code and other things that really add complexity to your overall app and grounds for code smells, or as I would call them, code cracks. Again, as I said, it's duplicate code length rule. Basically having a massive if you're talking about Java or object oriented programming language of your choice, you're talking about massive one class with no actual object oriented principle in place. And that will quickly deteriorate your project and force you to abandon it. Making it legacy Yagni violations, meaning that you add things just in case you ain't going to need it in the future, is a great way to write software. If you write something and you see it's not actually necessary, just delete it. Your source control might keep that information for the future, but also comments can deteriorate your code. Also, if you have a getter function, adding comment was it gets you something doesn't make much sense. You have to maintain comments as well, and it can pile up and get unmaintained very quickly. And it also adds to your brokenness of your software. And this book by Andrew Hunt and David Thomas pragmatic programmer has great suggestions how to deal with it, but overall refactoring guidance that I can provide for code smells, the field control always go for least number of responsibilities that your class or your method can have. Keep it private case of Java don't expose it too much because exposed things have to be tested very well. Keep data controlled collections. You can easily change things in the collection more often than not. And so you have to encapsulate it, hide it from the outside world as much as you can, because in that case it's easily testable. You have to keep things designed by contract, meaning that whatever you are getting that was you're returning is exactly as you promise things to do. If you get even number, you need to make sure you add an even number and you get that validated before the value is returned. And keep conditions and states in mind. That's what Java has a great addition to with optionals where you can really, instead of just returning null, you can return is it present or not? You don't have to just deal with nullable values. And another amazing book to reference refactoring by Martin Fowler. I really got a lot from it and whenever I dealt with refactoring of any kind. So that's all great. And we know now couple refactoring techniques, but how do we preserve behavior of our software? Because behave was I said before is the most important thing. So through tests, obviously, because I said legacy code is the code that's not tested. So we have to actually find a way to test our software to be able to change it. So characterization test is what comes to our rescue. They behavior driven and they are increasing our confidence. And what I mean by characterization tests, domain driven tests and domain driven tests are basically based on principles of domain driven design, which you don't have to know much about. Most important things are you have to know your domain, you have to know the thing you're working with. If you're working on accounting software, you need to know what accounting is all about, at least some basic concepts. If you're working with taxes, you need to know exactly what the lingo, what's the acronyms, what's these general functionalities that people who are in taxes need to interact with dog footing. You need to know exactly what you're working with, you need to use the software you are building, you're trying to respect the boundaries, basically set the domain you're in and use the same exact language in your code as you would when you're just speaking with somebody. And communication is a key, because again, it's all about communicating with your domain experts. It doesn't have to be you. It can be anybody from your company, it can be salespeople, if you're an engineer, your manager, PMS, et cetera. But is domain driven design useful in tests? And of course it is. That's why I'm talking about it, right? The main driven test pyramid, test pyramid as a whole, I'm sure you've heard of it, has unit tests that are the cheapest to have the fastest, but they give you the lowest number of the lowest confidence level in your software integration tests, where you're testing multiple functions of work, multiple units of work, and end to end tests where you're actually trying to use and test end to end scenario that your customers would go through. But they are the highest price, highly priced, they're hard to write, maintain, they're the slowest, but they give you the highest confidence level in overall systems, in overall application that you have. So the domain driven test pyramid is slightly different. It has domain enforcing unit tests which follow the same pattern, cheapest, fastest, lowest fidelity level, then the component approval tests and end to end task tests, which are the priciest ones, slowest, but give you the highest level of confidence. And this pyramid is important to us because it really helps us to start tackling legacy systems. That's why I'm spending so much time on this part. All right, let's look at domain enforcing unit tests. You behave to test as if you were an auditor, you have to step away from your code just so much slightly, and see how the user would see it. It's someone who were to audit your code, try to write it as if it was your last day, meaning that you write code as if tomorrow someone else would have to pick it up. So make sure you document it enough, don't go overboard so they don't behave to chase you and find you explaining what that single function is. So make sure you keep that in mind. And invariance. Approval testing is the actual application of domain enforcing unit tests. And what I mean by approval testing is that you're trying to evolve validation as you progress, as your code progresses. It's requirements driven. It's not just assertions, it's very different. It's actually you are defining what is correct. You take in snapshots, for example, is these great example of approval test. It gives you high level confidence, higher than the regular unit tests, because they're not just asserting something, they are actually validated by you, but they are more pricey, they are more costly than regular unit tests would be. So talking about the domain enforcing unit tests, invariant approval testing, they are property based testing. And these are also schema based testing. For examples of property based testing, there is a framework called quick theory for Java or JSON schema validator for schema driven tests. Quick theory just give you an example. If I were to write a code, it's a very descriptive name because it will show up in your test report. You initialize your quick theory class, then you have basically comparison of all positive, you get all positive integers and you basically have this simple operation of combining these and what it gives you is the result saying you can't just combine integers and expect integers as a result because there will be overflow. That's what property falsified after two examples. And it gives you smallest and other potential falsifying value. And it basically gives you that adding to positive integers gives you positive integer. That is incorrect. And that's exactly what approval testing does. It's not just asserting that true is true or false is false. All right, component approval test, second level of the pyramid. That's a couple of examples of those. Text based testing, snapshot testing, visual testing textback based testing is the example would be text tests, framework tests for snapshots and aptly tools for screenshots or backstop js. If I were to go for open source solution, apatools also is a great solution if you want to scale your apps app testing. But backstop js might be a good proof of concept for screenshot testing and that's what I will showcase. So let's say I have a simple app where I have a flag and the name of a country I'm in and I want to switch the country and it gives me Canada. Or to press it. I specify a test for tablet and for the phone. I give a quick scenario that go just to the home page, wait, nothing, and just wait for the selector. And it gives me these results. It basically takes screenshots and make sure that these difference is there if it changed. And that's basically how the screenshots testing is working. And again, it's an approval testing because you can just run it and expect it to work. You have to approve these screenshots and say that's what I expect. Maybe now the beginning state is hello Canada. Maybe in another country it's hello America. So that's what screenshot testing is. And that's a great example of approval testing. End to end task tests are a bit more complex and they are again user centric. Testing behind it is where you're trying to avoid focus on individual interactions and you focus on tasks instead of going through, let's say login flow. You talk about it was send keys for the username, send keys for the password, click on submit, instead you say enter username, enter password. Those tips in tasks for user to log in rather than going in the particular interactions for your tests, instead of talking about page object model, we're talking about screenplay pattern. An overall conclusion is that you have to focus and keep it on user dimensions. User dimensions can be different. Web users, they work on client side and API users, they work on server sides and that's where your tests have to reside. For web users, example will be protractor. For angular and for API users, if you have a rest, API rest assured is a great way to test your user interactions. User services on the backend. Alrighty, so we talked about broken code quite extensively. Now let's look at your team in play and how it affects working with legacy systems. Domain driven design that I referenced before. It's all about communication, so the importance of a team work cannot be overestimated. Common design pitfalls that we all face as a team. It's the approach of one size fits all. We try to have a silver bullet for everything. It's dogmatism, it has to be by the book and that's how we have to do it. At a company level. There is no design evolution. Someone else wrote it, let's not touch that code. And it ultimately leads to design stagnation. So how do we tackle these pitfalls? How do we tackle these issues on a team level? Because ultimately it's what results in broken windows, in broken systems, domain driven design is how we're dealing with those common design pitfalls. So let's go one by one. One size fits all. It's importance of knowing your context. As I said before dogmatism, you have to use design guidance rather than just feeling going by the book. Instead of no design evolution, you have design evolution and just having stagnation, you're thinking about lifetime of your application. Great way I've seen people do it is they have a stamp on. Reevaluate this function in a couple of years and you set actual timestamp when you have to reevaluate that. So you know when it expires, you know these new version of Java comes up with a great optimization. Maybe let's reevaluate that so context talk about context, when it comes to context is the idea of ubiquitous language. It's the idea of speaking the same language whether you're interacting with your customer or interacting with your code. It's the idea of bound context and domain segregation. So the idea of ubiquitous language means that you're basically trying to make sure that engineers, your tests and your domain experts who can be your users, your pmS, your salespeople, they all speak the same language. You don't call your user class user and test account on tests side. You have to keep the same naming because it really simplifies how you communicate, how you have discussion during the meetings or even code reviews domain segregation, what it means is that you really know exactly what you're working with. You're working within your accounting system, you're working within your logistics system. Make sure you exactly know what you're working with. Design guidance that you have to provide to yourself and your users goes to context mapping. Minimalism and design by contract that I've covered before. Context mapping is basically, as I said before, it's exactly what I mentioned in these past of boundaries of domains is that if you're working with sales context, the fields that customers might have, it can be different from what support customer has. So in support, what matters is maybe the phone number, email, how many cases they had and how many things they bought in sales they care about, your tax information, the Social Security number maybe. So those things have to be separated and known by you as a developer as you're working with domain experts. The context mapping basically acts your documentation because it has to be maintained. Maybe it's maintained automatically by a couple of plugins for ides of your choice. It acts as a communication tool because you can talk to your domain experts using that map and it's really supposed to represent your current state of your system because then you can deal with it because it's hard to add tests to legacy systems if you don't know what its current state is. The galactic model language actually helps a lot with it. It's the idea that you just have box line and labels, the complex Umls. I honestly personally never used it to its full power because I keep forgetting what boxes are for, what with just simple box line label approach or as I said called galactic modeling language, I can describe anything really, even the context map if I wanted to. So design guidance, as I mentioned, important to give and set for yourself. What's important is to also have strategic decisions. As a team. You have to collaborate within the team to figure out how to approach your system, you have to absorb feedback. Whether it's from your customer, from domain experts, from testers, from the engineers have to all work together. And really it all comes to having experience diversity. That's why it's important to have diverse teams, because everyone brings their backgrounds to the table, their experiences and helps you to shape your software and make it much better. And again, as I mentioned before, you have to know the lifetime of your design. Don't just have an indefinite, never change class or even the module. Keep in mind when it might be time for you to revisit it. So what's the conclusion? Communication is essential in domain driven design and it's essential with dealing with broken Windows legacy systems. So what do we do beyond design project planning? If I were to bring that up? When people say long hanging fruits are great things to handle, easy things to handle, they're long hanging for the reason we don't not dealing with them because they're complex, we've never touched them, we don't know their context. Dog footing is important to keep in mind. Also keep in mind Parkinson's law, where the work expands to fill the time allocated. If you don't have deadlines or you have very far deadlines like a year from now. It was with a waterfall approach. Your work might just be expanding, expanding or as they would call feature creep would be coming up and coming up. So keep that in mind. And the Conway's law is very important to us because it basically dictates that your software represents your organization structure. So you have lots of legacy code, untested, unmaintained code, probably in your organization you have something similar going on. Silos people don't share information. That's what it basically corresponds to. So regardless, communication in the key, as I said, and communication, instead of having it synchronous within the team, try to have a synchronous communication. Don't just always jump on a call, maybe ping them first. Treat each other's time with value. Instead of focusing on reach time. How fast someone can get back to me like within a second, focus on response time. Can they reply to you within a day? Just set those expectations with your teammates, because expectations is what's important. And maybe if you currently working from home have names to faces, don't just have an avatar, behave your break face, or at least when you are on a call, have some picture of yourself so people know who you are. Because when they see humans, it's been proven by psychology that we actually more sympathetic to it as well to each other. So it might help, as you know. Again, what about human aspect? It's also something we should never forget. This example I always bring up is by Jeremy Ashkenis. On one of his posts. He basically was just sharing. And by the way, Jeremy is a great person in the open source space. He's contributed greatly with things like coffee script. But anyways, he posted this nice picture of himself enjoying the sun, trumpeting the water and someone made this not so nice comment, I would say, and it really brings up the idea that you have to be focused on positive things. There is never a reason to be rude. The art of unsent letters is what I usually guide myself by is if you are angry with somebody, write a couple of iterations of response to them, but don't send these. And maybe on a fifth response in the fifth email you can actually send it because it's not as heated as you were initially. Focus on improvements, maybe not the best when the project is ended, instead of talking, how do we improve? How do we make better? Let's celebrate our success that we finish the project and have proactive feedback. We often give negative feedback or very infrequently we approach someone and says say, great job, be proactive in that matter. And a couple of things that I suggest to learn about this field and just being kinder to each other. Brad Cannon had a great talk about kindness on one of the podcasts and there is a changelock episode on that. So that's all great, but how do we deal with work environment that we are all interacting with our teammates? So office and you, I mean, you used to have open offices. I would say it's not the best thing, but if you're coming back, it might be different. Office perks, often they're just office bribes. People are forcing you to go to the office. It ultimately takes away from your time at work or with your families. We often get the best work done on these plane we're used to when there was no Internet, no interruptions. And don't forget that work is just work. Don't work all hours of these day. Spend some time for yourself and for your family. So the main grievance with work sometimes, especially in the office, were distractions at home as well. Mobile devices are often to blame. Noise interruptions are also a problem. You have to set up boundaries and getting to the zone is actually very difficult with all those distractions. So talking about individual distractions like mobile devices. Before I used to have a phone like this, lots of pop ups, notifications. Now I have nothing. No pop ups. Very organized, those. And that's what I would usually go for. And with mobile devices, can arrange your apps. Disable all notifications, do not disturb mode all the time, and put your phone away. It's been proven that if you just put your phone arm length away from you, you won't be as tempted to grab it every 1 hour and then, and just check it with no reasoning whatsoever. Noise control is also important to keep in mind. Meaningless noise, like a white noise, can be useful. Having some sound support, like apps like brain FM, Spotify, or my noise, or whatever you'd like to use to get into that zone of working. Or noise cancellation, like earplugs, earmuffs, or noise canceling headphones, whether it's Bose or something else. And library rules are also important to set up, especially if you're working at home. Keep quiet in the library. Have the sync ping first from your teammates. Don't get them just calling you. Let them write you a message first and see if you're available to chat. Establish those office hours when you're in these main expert, or your expert, especially on the legacy system. Set up like maybe an hour or two a month or a week or a couple other week, every other week, so people can come up with questions and ask you and discuss these rules. Don't just assume them. Have those expectations set with your teammates and with your company. So we talked about teams, we talked about code. Let's get to talking about individuals. And when it comes to individuals and how broken code and broken teams lead to broken individuals, I have to talk about stress. And why would we talk about it? Right? Let's look externally first. There are many examples out these like from Electronic Arts, this infamous life journal post from a person who was talking about spouse who had to work overtime. It was back in 2004. Then there's another example where Rockstar had quite a few people working overtime as well. And ultimately people didn't focus, was didn't spend as much time with their families. Or most recent that I could find from 2018 was from Brandon, where people at telltale basically laid them off. Quite a large number of people. And I really like his statement that work is ultimately work. Don't forget about yourself. Don't sacrifice yourself for the work. And there are many more cases, of course, externally. But what about internally? What about your colleagues, your family and yourself? Nature is smart when it comes to stress. Stress has purpose. There was fight or flight response. Imagine back then when you would run through the forest, you would try to hunt these prey and you would see, I don't know, lion. And you either fight it or you flee. Hopefully you flee because the lion most likely will eat it. The same goes for sleep or hunger. We're able to sleep less when we're chasing our prey or enduring hunger while again trying to find something to eat to bring home to our families and things. These makes sense from biological standpoint. Why do we feel so sad so badly when we are extremely stressed? The reason is because there are different types of stress. There is a short term stress and there's long term stress. And long term you're trying to avoid not sleeping for a day too while you are preparing for an exam may be fine, but when you're not sleeping for months at a time, that's really going to make a huge impact on your health. And the conclusion that you have to incorporate a short term stress because it's useful and you have to eliminate the long term stress. And it's important to talk about mental fitness when it comes to dealing with stressors. Overall mindfulness comes to mind. It's the idea that you have to clear your mind, embracing solitude, not being afraid of being alone, and incorporating meditation as much as you can. If I were to go one by one with clearing your mind, it's that currently we have information overload. This talk has been going for a long time now and you probably already overloaded with a number of things. I said you have to have this information dump dealt with as well. So many news cycles, so many different things coming your way. Even in this conference alone. You have to know how to deal on what to pick and choose. You have to have one source of true one place you go to to save your thoughts, to write your notes and keep your single focus. Multitasking is overrated. You have to keep it in mind. And this is a great book to actually reference for dealing with too many things at once. When it comes to embracing solitude, I personally found that it's extremely useful having the quiet moments to yourself. Flow therapy. It's when you are in a sleep, it's in a sensory deprivation tank. No sound, no lights, really lets you be with yourself for a moment, learn about yourself and clear. It basically is to clear judgments, clear judgments at least. And incorporate meditation. If you've never dealt with it, there are many ways to learn. There's unguided meditation, guided active meditation like running. You get in these zone and you actually relax. But important thing is consistency. Don't forget about your health, your mental health. And if you have a hard time starting there is a headspace app repaired meditation or calm. All those apps, again, help you to learn about this practice. And if you're skeptical, there is a 10% happier book by Dan Harris, who experienced some issues in the past and he found meditation that works for him. But more sources of work stress that we're dealing with are long hours and productivity and effectiveness chase. So overwork and long hours, it's creatures of habits. It's basically working too much, having unreasonable expectations that we need to avoid. And this weird math, the reality that you're thinking you're going to put 150% today, tomorrow you're going to put another 150. It's not going to work that way. You have 100% to spare. That's all. If you work today, 150% tomorrow, you can only give 50. You behave to do hunger by and hungry if you can. But don't go overboard, because ultimately it leads to regrets. And if you think you won't have those, I doubt that, because there is a great book by Brony Ware, the top five regrets of the dying and anybody who has been at the death door. She basically collected these five top regrets, and one of the top ones were working too much. And again, keeping the productivity and effectiveness chase splitting hours doesn't really work well. You have to know that you can either have a 60 minutes focused or you're going to be interrupted. And it's not just 15 times four. You have to get in the zone, you have to get in the context. It doesn't code for free. So you have to keep focused and use benefits like unlimited vacation or health reimbursements, or buying equipment for yourself, like bikes. You have to actually use them if your work provides them. Because ultimately, if you don't go into conferences, if you like the field you're in, it leads to lost passion. You have to challenge yourself. Try to learn a new skill. Try to tackle a new language if you can, programming language if you can, or do it for yourself. Read a book. Read a fictional book. It really gets you going. Because if you just set in one way, it ultimately leads to too much stress. So are there any gotchas? Yes, these are. Of course, there are some receipt ways to fail. It's to be dogmatic. Just do it by the book. Jumping in too fast. It's like running a marathon. Many people can run a marathon with no training, but after that you won't be able to move for like six months or something, especially running for six months. You have to set goals for yourself, realistic goals and fighting your own nature. Doesn't work either. Try to see what works for you. Going cold turkey and not eating anything sweet like I'm trying to deal with, it's not going to work. You have to let yourself have a cheat days or again, whatever works for you. And this book that I found very useful for me to find a way around my habits on the day, on your life. Very handy by Aubrey Marcos so there is so much information that I talked about today. Who do we trust? Find a specialist, talk to a professional, experiment what works for you, and share your experiences with others. I'm sure you'll find people who can connect and relate. So to the last point of sharing, though, I skipped a major part the beliefs. To stick to your ways to improve yourself or improve your mental fitness or help yourself, you have to find inspiration, find purpose. For some people it's health, some people it's parents, kids know for why you're doing something. Find your community. And overall, again, I've talked about so many things, about code, about teams, about individuals. It's all about you. Finding what resonates with you throughout this talk. Taking it back home, try to apply it to your work, to yourself, and pick and choose. And so call to action for me is welcome. That change. Lead by example. Your team will change if you change yourself, they will see that. Communicate your ideas, your expectations and experiment. Give it a try. So connect with me on Twitter, read my blog, link in or email me directly with any questions. And again, thank you for your time. Thank you.