EU Targets Big Cloud, Brazil’s Emergency Alert Breach & Token Economics | SS #34

This week on Software Sundays, KD breaks down three major stories shaping the future of technology, cybersecurity, and business. We start with growing antitrust pressure on cloud providers like Microsoft, Amazon, and other infrastructure giants, and what it means when cloud computing begins to look more like a utility than a traditional technology service.

Next, we examine the cybersecurity implications of a hack that allowed fake government emergency alerts to be sent to millions of people in Brazil. KD explains why trust in digital infrastructure matters, how attacks against critical systems can create national security concerns, and why cybersecurity skills are becoming more important than ever.

We also explore the changing economics of artificial intelligence as AI companies move away from flat subscription pricing toward usage-based models. What happens when organizations are forced to measure the real value generated by AI systems? And what opportunities could emerge for engineers, operators, and future FinOps professionals?

In this episode’s Q&A, KD covers pass-by-reference versus pass-by-value, who should define security policies, why undocumented processes create operational risk, lessons learned from debugging a production issue, and how to build software that people actually want to use.

We close with a reminder that uphill battles require stronger teams, better preparation, and the right people around you to keep moving forward.

Timestamps:

00:00 Introduction to Software Sundays and Antitrust Laws

09:34 Cybersecurity Threats and National Security

16:59 The Economics of AI and Value Testing

24:13 Future Skills in Tech and Professionalism

29:09 Memory Management in Programming

33:49 Defining Security Policies in Organizations

39:57 The Importance of Documentation

44:15 Lessons from Debugging Production Issues

49:05 Creating User-Friendly Software

53:23 Overcoming Life's Uphill Battles

55:00 Announcements

Build Learn Impact is on a mission to help people create wealth and opportunity through technology.

Subscribe if you're ready to build, learn, and lead.

#SoftwareSundays #CyberSecurity #AI #CloudComputing #AWS #Microsoft #Amazon #CloudInfrastructure #Antitrust #BrazilHack #Technology #SoftwareEngineering #FinOps #Leadership #BuildLearnImpact #ArtificialIntelligence #TechNews #SecurityEngineering #Git #Programming #Developers

DISCLAIMER: This is not professional advice. The views expressed are my own. Consult your own legal, business, financial, or tax advisors before making decisions based on information discussed in this episode.

Transcript

SPEAKER_00 0:00

Software Sundays is for informational purposes only and is not professional advice. Please consult your own business, legal, or tax advisors before making any decisions based upon information found in this show. Thank you. Welcome to Software Sundays Builders. I'm your host, KD, and in this series, we have high-level conversations about technology and the impact that it has on our community. I want you to have the tools that you need to grow your income, become an owner, and help shape what happens next in the world. This is your first time tuning in, you are in the right place, and if you've been rocking with us for a minute, it is great to have you back. Welcome back. Thank you. Let's get into it. First up on the news for this week is EU antitrust laws may be directed at Microsoft, Amazon, and other cloud service providers in the future. Right now, the EU has a framework called the Digital Markets Act, and it's designed to stop gatekeepers from being able to influence the markets pricing and just the economic activity that they are enabling. And it's part of their antitrust laws, which would stop large companies from being able to have unnecessary power and too much power over the people that they serve and other competitors. So these are positive things that we would want to encourage, at least from a high-level standpoint, you want to encourage antitrust laws. But in terms of implementation, that's sometimes where it gets tricky. It's difficult to determine when someone is operating as a as a as a gatekeeper and as some company that's going to have negative impacts on the market. So cloud companies are potentially becoming part of that scope. So it was interesting to me to see it or to see this story because when I think of cloud infrastructure, I don't I think that it's important and it's one of the key resources that every society needs, every nation needs, from businesses to individuals. We're all using the cloud in some way, shape, way, shape, or form, especially governments. So it was interesting to see that the government is looking at these services as something that we hey we need to keep a closer eye on. But it's different than the traditional services they would seek to, or I'll say in the most recent years, when you see antitrust laws today, it was, or there was a question about whether Google was going to be caught up under those antitrust laws, right? And were they too big at the time with their Google search and how they're kind of monopolizing the market for advertising and search? That came up as a question. And even that eventually got dropped because I guess there wasn't enough evidence to say that they were a monopoly in their specific industry, their market. But when we think about in the past, the types of companies that were labeled as monopolies, if you think about Oyu and the Rockefeller Company and how that got broken up, you think about different telecom carriers, ATM, and or even think about more recently, certain airlines being prevented from actually merging. Those companies all have one thing in common that they directly serve a customer and they provide a they directly serve individual customers, right? So you're talking about millions of customers at a time. Cloud companies, while they are just as important as airlines, as banks, as no telecom carriers, they are not directly serving a customer. They are they're serving a business who uses their services to serve another customer. So that's almost an expansion of the scope, right? It's no longer just if you directly serve and interact with individuals. If you have any exposure to the market that customers are using, if you're operating at an intersection that can have or can express undue pressure on your customers, on your clients without them having enough options, not optionality and you know other ways that they could go around you, then you become, according to this potential case, a monopoly and someone that needs antitrust laws implemented against them. So it's very interesting from that standpoint, and it goes back to the fact that I've mentioned that these technology companies, especially cloud service providers, they're becoming, and I'll say becoming, but they are like any other utility today, right? You cannot run your business, you cannot run your country, you cannot do anything without having access to the latest and greatest technology. And the latest and greatest technology is often delivered as a service by a Google, by Amazon, by Microsoft. And that yes, there are smaller competitors in the space that might provide VMs or they might provide unstructured source storage, data storage, and even databases, right? If you think about Mongo Atlas, that's their cloud service or their managed service for providing databases. Like all of these services are so important to the way that society works today that without any regulation, it can quickly become, I'd say, high pressure for the customers and the users of those services. On the other hand, AWS explicitly is contesting the label as a monopoly, as someone that needs to be regulated under these laws. One, because there are other laws that regulate them that require them to make it easier for customers to switch, make it easier for them to, or make it more difficult for them to lock customers in with long licensing agreements. But also for the fact that I mentioned that they're not directly interacting with customers and users themselves. But at a certain point, when do we consider the businesses, the clients that use their services, entities that require some protection, right? If you're talking about literally, literally anyone could create a business. But if you have those types, if you have monopoly like protections on a cloud service provider that all of these businesses need to use, and let's say everyone who is in the nation that wants to start a business, if they all have to go to your company to deliver their service to actually compete inside of a digital world, then you kind of are a gatekeeper in the space. So it's interesting from that standpoint. Of course, they are fighting it. Who wants to be facing more regulation, who wants to have higher costs for compliance? But it is interesting to see how we're expanding the definition of a monopoly, how we're expanding the requirements of a business in 2026 and beyond, and even thinking about you know what services can we just not live without. So something to keep in mind as you're building on any of these cloud providers, if you ever hear the term multi-cloud or cloud agnostic, that's the whole point that we're describing. Most companies want to be able to shift from AWS to Azure to G Cloud or to their own on-premise data centers and workloads. Because when you're locked into a specific platform, either through the authentication methods that you use or from the high cost of data transfer or even just the networking incompatibility between different providers, that makes you more reliant on one service, right? Imagine when or think about when AWS had gone down for a few hours. There were hundreds of companies throughout the globe that were unable to access their services, unable to serve their customers. That's not the type of situation you want to be in, or for any customer for anybody, but especially for a company that has their own SLAs to reach with their customers. They have their own delivery and quality that they're trying to hit. Being at the mercy of this company being on time, working all the time, and just keeping up with their requirements is a bottleneck that no one really wants to have that type of third-party risk. Another news: a hack leads to millions in Brazil getting a government, a fake government alert into their phones. This was a very interesting story from a cybersecurity and national security perspective, because the equivalent of the Amber Alert system, like the emergency alert system for that country, for Brazil, was hacked, and those hackers were able to send out a message to millions of citizens that came from a trusted source, right? Everyone, when you get an Amber alert or that emergency broadcast system message, you trust and assume that it's coming from a legitimate source. You trust that it's coming from a government and you trust that whatever message is being sent to you is accurate. And so when we're seeing that trust be shaken, when it's being disrupted, because the message that came through was not actually from a legitimate source, it was not accurate, it was not supposed to come through. That's a very that's a bad position to be in from a government standpoint. So that was very interesting. Another interesting part about this event was that the message that was sent was classified as an extreme alert, and the message itself was misanthropy. It was just one word, a single word that means hatred towards humanity. And I don't think anyone knows what that means. Not knowing the definition of what it means, but knowing that who's whoever sent that message, were they saying that they have this hatred toward humanity? That's if that's the case, then their hatred combined with their skill to be able to hack into and take control of a national system that should be under the most strictest controls, is alarming. Because what else can they take control of? What else say what else can they take control of? But what else could they have done with this message? They only sent one word that didn't actually prompt any reaction from anyone. But imagine they had sent a message that was designed to prompt an action. Imagine they were sending a message that was designed to destabilize a bank or destabilize a no a what do you call it, a political not movement, but a political activity, right? What if this was election season and a message was sent to make it more difficult for the people that would vote for a particular party to feel comfortable heading to the polls. That's the type of things we're trying to combat when we're talking about cybersecurity and protecting digital systems. Software infrastructure that we rely on from the cloud to the systems that actually are powered by the cloud. Whether it's your phone service, your telecommunications, and how you message and communicate with your family, friends, and business partners. Whether it is your Uber and how you transport goods, right? It could be the systems that UPS uses to track inventory and track where their assets are in relation to an active delivery. Or it could be Uber and how vehicles are moving and how people are moving goods throughout a city, or it could be something like a bank who is keeping track of people's savings accounts, their retirement accounts, their brokerage accounts. Like these systems need and require the utmost security. They require people that understand how to keep out the bad guys and malicious hackers. They require people who understand what it takes from a performance standpoint to actually secure a system and maintain the security of that system over time and in the event of any type of failures, right? When something breaks, what actually happens? What are the next steps to get the system back in line and back functioning? This becomes a much more important requirement that it may not have been so important in the past, but it's getting progressively more important today. And that's a that's with systems that have a less than physical reaction in the world, right? I'm talking about systems that they aren't directly tied to human behavior, right? Like I can't send a text and it automatically makes a human do something, or it doesn't automatically change real world conditions, right? I'm not seeing technology is that type of technology, although it exists, it's not as prominent, it's not as well say diverse and no common. When you have that type of control being possible through these software systems, we get into a point and we get to a society, an environment that could be very dangerous to live in. So I really want to emphasize how important it is to have the skills and understand the different domains for cybersecurity, understanding the software development architecture that you need from a security perspective, right? Do you have a software bill of materials? Do you know what dependencies your application uses? Do you have a change management process to keep track of any types of changes that negatively impact the performance of your software? Do you have a way of testing the security, either of testing it from a static perspective, making sure that there are no input validation misses, that you're not having any type of vulnerable dependencies, but also from a dynamic perspective, have you tested type of data that your application has access to? Have you tested how well it performs when there's some type of fuzzing attacks implemented on it? These are things that become incredibly important from a professional standpoint when we these systems gain more popularity and more uh critical standing inside of our society. And finally, meter pricing is currently testing the economics and the value of AI across the economy. So let's think back to 2023 when ChatGPT first released, or when OpenAI first released ChatGPT, and people started seeing what could be done from an LLM, what types of reasoning. Back then it wasn't even reasoning, but it was really just generation, text generation primarily. From then fast forwarding to today, the amount of reasoning capabilities that we have from these models has definitely improved. The cost per token has definitely improved. But we've also seen an exponential increase in the amount of services that use that underlying technology that rely on LLMs from agency workflows to normal chat-based systems. All of these systems have increased the amount of tokens actually being used. And originally the pricing model was from a especially from a consumer perspective, was you pay $20 or $200 for the subscription, and that subscription will get you through the whole month. Now we're going into an environment where that type of pricing model doesn't accurately describe and doesn't accurately capture how much value is being generated by these machines, by these systems when you deploy them. Versus the person that's just sending a prompt every once a day just to ask about the news or to ask chat, tell chat about his day. That person is spending significantly less than another person. And there were also some also some other subsidies that were coming from the investments perspective where people were just saying, hey, when I was saying the businesses in these labs building the models were saying that we'd rather keep the cost low enough to drive adoption versus setting up competitive pricing to actually increase revenue or increase profitability. For a long time, profitability was not the primary concern. Now, most of these companies, I'll say most of them, anthropic and open AI, are trying to go public. And so public companies need to have some type of path toward profitability, or else they don't work. It doesn't make sense, especially considering the amount of investment that they usually get. So now we're testing the value of these AI systems. We're testing and having to validate whether or not the financial services company financial services company, whether it's a bank insurance company or whatever, whether or not the assessment or the assumption that they made when they said it would be cheaper to hire or to bring on this AI system than it is to hire and train up a junior analyst. Right? We're gonna be testing that moving forward as these models continue to get deployed throughout different areas of the business. But it also tests the value of AI literacy because now it's not just do you use AI? It's do you use AI intelligently? Are you using AI to ask a question that you could Google, right? Or are you using AI to help close the gap between a you know your current state and a future state that actually required significant amount of energy from you or significant amounts of time? And is that is the actual business value being felt by the prompt that you generated? Right? A few months ago, there were companies like Uber and Meta that were actually setting up leaderboards for who could use the most tokens, which is a very unnecessary metric to capture because using the most of something doesn't mean you're using it in the best way, it doesn't mean you're using it efficiently, it doesn't mean you're using it for anything good. I remember seeing a meme a few meet like months ago, and it was talking about what it was like a Star Wars video. It was Anakin talking to uh Padme, and Padme was kind of asking Anakin why AI data centers or what what was the value of these data centers with AI? And she was saying, I think it's because we can. You know, solve difficult problems, we can help you know and improve healthcare scenarios. And he was basically not agreeing with that. And when you zoom out, it's like, oh, we're just using AI to generate images that may or may not be appropriate, that may or may not be valuable to human development, that may or may not be helpful to any of the major sectors that we that actually exist in the world. So that question is really coming up today. It's like, you know, we don't want it being unproductive is not just not using the tool. Being unproductive is using a tool in a way in an ineffective way. I won't even just say the way it's designed to be used, because you can be creative and use it in a way that wasn't expected. But if you're using the tool and it's not really getting you the results that you need from it, it's no point using that tool. So this is going to be a very interesting time from an investment perspective, too, because if the value of these models is not felt as quickly as the price is felt, right? If the costs start going up more than companies start seeing the value of it, they might decide to cut down on how much they're spending. We're already seeing caps on the amount of uh tokens that an engineer can use in some companies. We're already seeing decisions and strategies to move away from some of the frontier models for every workload to considering some of the open source, you know, basic models for some use cases because they might give you the same or similar results. And that changes the economic value of the investments that people are making inside of AI from the software perspective to the chip perspective and everything below that. It definitely becomes a question of where is the actual bottleneck for value and who is going to get the benefits of that bottleneck moving forward. But another future role to consider when we're thinking about the future of society, AI, cloud is that FinOps, which is the tracking and optimization of cost inside of the cloud and inside of any type of cloud spending, having a way and a strategy to optimize that, having a way to think about tracking cost, budgeting costs, predicting costs over time based on workloads, based on use cases, that's going to be an incredibly valuable skill. And we can all start that, and you can start that in your life today with just understanding budgeting, understanding how to calculate the value of something and how efficient it is based on what you're getting from it. So be able to understand the PL and understand how to create that PL for a technology company, for a service inside of an other company, other type of company, and how you can connect that to the technology being used inside of that economy or that uh company or sector. But the major thing that I want to just highlight for this week is that the tech industry is not just a place for hobbyists, right? The real-world consequences and the real world considerations from financials, from ethical and legal consequences are something that every professional going into the field needs to understand. And it's something that requires a higher level set of thinking because you can't just go in there thinking we're going to play with computers. You have to go in there with a level of professionalism that allows you to understand that you're going to serve a customer, you're going to operate inside of an economy that might be regulated. Right? The technology you use is that likely to be regulated. There's likely to be some actual laws that you have to comply with in order to do your job and do your work. If you're not understanding that, then you're going to have a very difficult time being successful over time in the field. So something for current developers and aspiring professionals entering the field, you just need to understand how important it is, what you do, what your skills are, and what you're actually going to be delivering when you do enter the work. But if you want to go deeper into any of these topics and explore the opportunities that they create for you and your family, join BLI University. Every week we're having some of the biggest conversations about the changes happening behind the scenes and how they impact the environment, society, and the economic world. And we're doing that with a community of builders who are not only watching what's going on, but they're actively building and driving some of these transformations that we're seeing inside of the economy and all these different areas of the world. So we'd love to see you in our classes. So we're going to jump into our QA section for this week, starting off with what is the difference between pass by reference and pass by value. This is one of those fundamental concepts that you need to understand from a programming perspective, right? This is a software engineering topic, understanding how data is moving throughout your application and what that means from business logic standpoint and what you can do with that. So in primarily compiling languages or compiled languages, one of the more memory-efficient aspects of those languages is the fact that they don't duplicate entire objects when a function is called, right? Or when you're passing a function or a variable to a function. When you pass that variable, you can pass the address of the object that you're referring to. And that that address is going to be where you can locate the object, but it doesn't require you to copy the however many bytes of data required for that in that object. That's what pass by reference is. If you're passing by value too many times throughout your program, then you end up creating duplicate versions of that data. And you can run out of memory very quickly in that type of environment. And it's also a bit slower, not significantly, but it can become a bit slower because now you have to go through the operations to duplicate that data. And the data could be large enough that it requires extra cycles from the CPU or the GPU running those operations. So it can make it slightly smaller in most use cases and most operations and programming, that might not be the bottleneck that matters to you. The data size is actually going to become an issue, especially in like a language like let's say Java, where you can run out of memory very quickly. There is a garbage collector, but even having the garbage collector remove some of those unused references over time with those unused copies, that again, it just takes extra cycles. That if you want the fastest, most efficient program, you don't need that, you don't need that, and nor should you want that happening or needing to run too often. Pass by value also changes what you can do from a functional perspective. If I'm passing an object to a helper function and I do some trend, like I do something with the data, either I you know change the value. If I pass a reference to it, that actual object everywhere else in my code and in my program, that value is going to change. So if you're not expecting that, that can result in some bugs because you may assume that the data is going to be in some format at this step, but you already passed it to a different variable or to a different function that changed and updated that value. And now that that value is changed, if you don't expect it later on in your program, that will cause some issues in terms of it could just cause bugs that you weren't really prepared for. It requires less memory to pass by reference, which can make the application that software a little bit faster. Passing by value is often, I'm saying it's unnecessary. Like you don't need to do it if you don't, if you can avoid it, you can avoid it and you should avoid it. But there are probably some use cases where you want to pass by value, especially if you're passing data to a function that you expect to change the value that it gets or the copy that it gets, but you don't actually want to save those changes. And if you know you don't want to save it, you might as well not even pass it to that variable or to that function. You're better off just making a copy of it or passing by value and having that value that copy get updated. And then once the function returns, once that function is uh you know finished, it can just delete, or the the system will just delete that memory address to that copy. So you never even have to worry about your main value, your you know, your clean value being changed or updated in a way that you didn't expect. So that goes very deep into data architecture and data structures and whether or not you're being efficient with the underlying resources that we have, like CPU, like memory, like uh in say storage, right? Who should define your organization's security policies? So very quickly, any policy defined by your organization should be set by management. Whoever is the top person in charge, they are giving the instructions. Think about it like a chain of command in the military or in any type of military-like organization. You have the orders coming in from the top and they get completed by the people on the bottom or the people below them. And yes, an officer of a higher rank can delegate authority to create a policy to people below them, but even still, that chain of command follows into whoever is responsible for that area or that team or that outcome. The person responsible needs to create the policies, they need to define what is okay, what is not okay, what we do in between these scenarios, right? Like if something is not okay, they need to be the people that say this is how we get to the system being okay. From a security perspective, in many regulatory frameworks, there are actual roles that need to be filled in order for an application to meet the requirements and compliance, the compliance requirements expected of it. Right? A data owner, the person who is responsible for saying what data needs to be collected and how that data is used, they're responsible for making sure the security policies around that data are not only defined, but that they are applied and audited regularly. If we're thinking from a technology operations standpoint, the person responsible for the application and the success of that application, they're responsible for making sure that the change management uh process is defined, that there's a configuration management processes, that there's a disaster readiness and uh business continuity processes all defined. That's from a higher level, right? Now, again, you can delegate that authority to the reports under you, but at the end of the at the end of the day, the person who is the owner is the owner, they're most responsible for what happens. Now, when you get delegated some type of authority, when you're getting some responsibility, whether the responsibility could be to implement a feature, or it could be to set up some application or set up some process. Now, you still have to comply with the standards that have been defined above you, but within that area, within that box that you have authority over, you should feel confident to set whatever policies you feel like are necessary, right? Now you can't define the budget, or you may not be able to define the budget for your entire team, but if you've been told to implement a logging and monitoring solution, as long as you're operating within the budget and within the policies of your team lead with your director, you're good to go. As long as the system that you design makes sure to comply with the other policies that are going to be, you know, in scope for you and what you're building, you're good to go. So you should always feel as comfortable as possible creating policies for the thing that you're working on. And if and when possible, make sure to you know make it clear what direction you're going into. You want to make sure that you're as often as possible, as early as possible, setting a clear expectation for what direction you're gonna go into. Because if it hasn't been defined what you can do, like what the guardrails are, and you go in a direction that is kind of ambiguity and ambiguous, then you have to be able to speak to that, you have to be able to defend that, and it has to get buy-in eventually from the people that set the policies that you have to follow, right? You can go pretty far for a long time without them saying anything, but at some point, when the policy gets applied, at some point when someone starts to say, oh, we have a gap here, let's create the policy. If you're not operating under that umbrella the correct way, then you'll have to very quickly pivot. And that could be a more challenging situation because you kind of went and designed your solution in a way that you thought this was okay, but now that things changed around you, it's no longer okay. I've had that problem recently with an automation I was designing and implementing where there was a security policy that had not been clear when I was architecting the solution, and I had gone through several reviews with the technology team that would help me operate and build that solution. But on the back end, when I had to get the agreement and a confirmation approval from the security cyber team, that became where I realized they're not going to let me move forward with this solution. And it's not going to be the it's not going to work anymore. And that at that point, it wasted weeks of work and weeks of deliberation going back and forth, weeks of design, because now the design no longer works, because it's no longer supported by the policies that are in place. So something to keep in mind and you know, look into as often as possible, or and as early as possible. Why is it risky to have processes that are not documented or shared? So you may or may not hear of a term called the bus factor. And that really just means how close is your operation to failure if the key person gets hit by a bus, right? If the person who understands the system inside and out doesn't make it to work tomorrow, is the business able to continue without that? Or are you forced to halt? Can you no longer serve your customers? And how long do you go without having the ability to resume operations, right? How quickly can you get someone else set up in that role or get the system redeployed so that you can continue to deliver value to the people that are relying on you? That's why it's an incredibly risky decision to make when you don't document processes, when you don't have SOPs defined for deploying your application, for rolling back an application, for migrating your database, when you're just doing things ad hoc, when you're doing things and just, I won't even say shooting from the hip. Like you're doing things and you might be careful while you're doing them. But if you're doing a process or you're doing some type of activity, let's say you're creating a report, but you don't define what you've done, rebuilding that report in the future is going to be something very difficult. It's not going to be something that you can do easily, or you can do it for a while through muscle memory. But what happens when you're not available? What happens when you take a few weeks off and then try to come back and go into the process that you haven't defined and you forgot a step, and now some key data point that you know you shared, or some key aspect of the output that you created is no longer accurate, but you're trusting it to be accurate, but you never really audited the process, you never defined the process, and so now gaps are being missed, or big gaps are being felt. This is the main problem. Another problem is when a team member leaves, right? It could be a permanent leaving of a team. The more information and knowledge that exists in one person's mind, the more difficult it is for the person inheriting that system to do any type of knowledge transfer. Let's say I get some application, and the only documentation is the fact that we know it exists. We know this application exists and it's running in this environment. We don't know what credentials it uses. We don't know what business process it actually supports. We don't even know who worked on it before. We just know it exists, and we know that needs to continue to exist. The best case scenario is that you're operating a system that doesn't need to exist and that could very well be decommissioned, but you don't know because you don't even know what it's supposed to do. You don't know who it's really serving. That's the best case scenario. Worst case scenario, the system actually goes down and you need to migrate it to a new environment, or you need to re set it up again in some other clean environment because maybe the initial environment that it was in got compromised. But you don't have the credentials that it needs, and you don't know where to get those credentials. You don't know what configuration it needs to work inside of a new environment. You don't know what environment variables to change. Like there are a bunch of things that can happen. That can make it so that you no longer have access to this system, and poor documentation is the worst thing you want to have when that time comes, because it will come at some point. What was a lesson you got from debugging a tricky production issue? So I got this question recently during an interview, and one of the most challenging debugging sessions I had was figuring out why my logs for a Java Spring Boot application were giving me logs that I knew could not be accurate. It was telling me that a health check was being performed by members of the team or individual members in that business that they wouldn't even have permission to access that endpoint, as the endpoint was only accessible within the pod. So it was something I was like, I was seeing, and then it also expanded to system generated or to all system generated activities that were being logged under people. And that may not sound like a big problem, but when we're talking about a log that is used for auditing, when we're talking about a log that is supposed to be there to say that this person did this and be able to, you know, strongly know when and how like people were operating the system, when you have that type of reliance on the logs but to know they're not right, that's an actual business failure. That's an actual risk to the business and to the success of that feature. So for me, it took me going through the logs and data dog and actually just reviewing them for a while, like understanding kind of what request was I looking at. And every request, like some of them would be accurate. So it wasn't like a persistent, incorrect data. Some I would see, okay, this is accurate. This is how it works. This is what I expected. But then some requests, like I said, were showing up in a way that I knew were wrong. But the pattern that I noticed was that when a request would show up wrong, the wrong data was actually the same data as the correct request that came right directly prior to it. So I was able to see that, you know, that timeline inside of the logs I was looking at. And then I was able to see the context about those logs, one being like the the person we were saying did the action. But then I also, once I was able to see that connection, I was able to see and notice that the issues, like the other similarity, was that the issues and the logs that had the issues were all were running on the same threads, right? So that became the problem that I realized the thread was not being flushed correctly between requests, and that I hadn't beforehand really thought anything about threads and the memory that they were using. I knew that every request would get its own thread, and that's how we could get you know the illusion that multiple requests were being processed simultaneously. But I hadn't thought about the fact that when you run a thread, it does save data between those requests. Like every time a thread is open, it's not that it's a new thread, you're just pulling, or it's in a Java environment, it's pulling an existing thread from the thread pool and then giving that thread whatever the most recent request is. And so there's data that's saved between those requests. So in this scenario, there was no sensitive data that was being leaked, but this could also lead to a problem like that if you have protected information, personal identifying information being logged or being stored in a thread that doesn't get flushed, it could possibly and potentially be reused and exposed inside of other requests. So that situation taught me about thread safety, it taught me about reliability, and it taught me to think about data in a different way, to think about data privacy a little more than I was at the time. How do you define software that other people actually want to work with? So I'm currently working on a project that I build tools to improve the information security processes for our application team. I'm currently working on a tool to automate the refreshing of a tracker that we're using to track compliance. And I was like today, there is a team member that does this work manually and he does it whenever he's available. But going back to the bus factor risk, whenever he's not available, the data is often not refreshed, and there's usually no indication that it hasn't been refreshed. So I am considering and building a solution. I'll say it's about 80% of the way done, where we can automate that entire process and get it, get our refreshing process to be within a few, like less than a minute, but also be a little more reliable where anyone can run the process. So it becomes incredibly important if we're saying anyone can run it, that anyone feels comfortable running it, and that they actually want to run the process versus having to go through all the manual steps that the current person responsible for that activity is doing. So one of the things that I'm thinking about from a reliability and a user perspective is having documentation, like having a simple summary of this is what this script does, this is what this automation is here for, right? Having that context available for whoever is going to pick it up, whether it's someone that's familiar with the process or someone who is not familiar with the process. That's going to be incredibly important and helpful to them. But I also need instructions for how to use it, how to install it. Like what prerequisite tools did you need to install to actually run and get started with this tool. Now, this tool is built in Python, and I may eventually have some UiPath components added to it. That means that whoever is going to use it, they need an environment that has the Python runtime uh installed on it. They need to be familiar with how to run a Python script. And now I can make it as simple as possible, but if they don't have those prerequisite skills or those prerequisite tools, it doesn't matter how user-friendly I make it. It's not friendly for the user I'm giving it to. So understanding who you're giving it to and what their needs are, what their capabilities are, is very important. And that's like instructions for how to get started with it, but also instructions for how to run it and understand the inputs and outputs that you need. Right? We want to make it so clear to someone that picks up this tool what they can do with it today and how they can get immediate value out of it. So that all requires documentation. That all requires the developer having a clear understanding of the business process that they're in the business workflow flow that they're solving for. And so that's all I had for this week for our QA. I hope the concepts and the topics have been valuable to you. Hope you can think about and have learned from some of the experiences and the tips that I've shared so far. If you want to have further conversations about any of these topics, if you have extra questions, uh send them my way, and I will go in more detail when the time comes. So, quick mindset shift before we get out of here is that uphill battles require a stronger team, better training, and more resilience. And most of the challenges that we face in life are going to be uphill battles. Your life is always going to be a challenge that you have to continue to push and to continue to strive to see progress in. Now, personally, I'm challenged every day as a human, as a husband, as a son, as a brother, as a professional, as an entrepreneur, as a landlord, and as a citizen. Right? There are things that I want to improve in, and there are actual forces that seem to make it difficult for me to do that. And that's fine. That's fine. As long as you're aware of the battle that you're fighting, as long as you're aware of the challenge that you're going to be up against. You should prepare yourself for that type of uphill scenario. You should prepare yourself to have to face headwinds. You should prepare yourself to have to go up against Goliath and people that are stronger or systems that are stronger. And that don't mean prepare to go up against them and you have to be stronger than them. Sometimes understanding you're going up a whole uphill battle means you may have to go sideways for a little while until you could get enough speed or until you could get enough strength, or until it becomes a little less uphill when you go sideways. But I would say, even another thing about uphill battles and the thing that you need in order to continue to go through those scenarios and those situations is having people that you can rely on whenever you're not in battle, whenever you want to take a break. Because they're gonna give you and help you get the strength that you need to actually continue to battle, no matter how difficult it becomes, how long it takes, and things like that. Like when you find those people, invest in them. Spend time with them, invest time, money, energy, whatever it takes, love. Like you want to make sure that you have all of the resources. And that can that is usually people, nothing more important than people that you can count on so that you can continue to go longer and faster and stronger in whatever it is that you are working on. So if that uh helps you to you know get past whatever challenge you're having, it whether you're a student, whether you're starting a new job, or you know, jumping between careers. I hope that you understand and that you are prepared for the challenges that you're going to be, you know, facing moving forward. So good luck. I encourage you to keep going. I encourage you and I want the best for you. And quick announcement before we get out of here. Happy birthday to my first big little brother Kev. I wish you the most love, I wish you the most peace, and I wish you the most just understanding that you are the best at the things that you do, and that I hope you continue to enjoy the things that you do. Like whether you are enjoying, or not even whether when you enjoy your dancing, I hope you enjoy and continue dancing and enjoying how you express yourself inside of this world, and that you I hope you know that I have your back and that you trust that I love you and that you are you are a great person, and that you have everything you need in order to be the greatest person you want to be. So continue doing your thing, my brother. And happy Father's Day to all of the fathers in the world and that are doing their best. There are plenty of fathers in this world that definitely deserve a lot of respect and a lot of love and support and appreciation for all everything they've done for their family, for their children, for their significant others, for the people that rely on them. So I hope you are feeling appreciated for your efforts. I hope you are feeling well taken care of on this day and on in this time. So happy Father's Day and enjoy. And we have a software engineering class on Tuesday at 7 p.m. I'm gonna be going over the introduction to version control with Git. We're gonna go over the background for Git, GitHub, and installing the Git CLI, creating a GitHub account, and some other frequently used commands that every developer should know before they start building software, before they build software in the enterprise environment. So look forward to that. I will be sharing the invite and the call links inside of our Discord. So look out and I hope to see you. With that being said, happy Sunday. Have a great day. I will see y'all in the next one. Peace out.