AI in Housing, Anthropic Hype, 401(k) Changes | Software Sundays #24

This week on Software Sundays, KD breaks down a major shift happening at the intersection of technology, policy, and opportunity.

We start with how AI is being used in housing for loans, leases, and pricing, and why the rollback of discrimination safeguards could make biased systems harder to challenge. Then we get into Anthropic’s latest model claims, the suspicious timing of recent leaks, and what all of it says about hype, trust, and the current state of the AI market.

KD also unpacks the proposed 401(k) rule changes that could open retirement portfolios to private equity, private credit, real estate, and crypto — along with what that could mean for everyday investors, founders, and access to capital.

In this episode’s Q&A, we cover why root and admin access should be used carefully, what it really means when people say data is the new oil, how strong engineers debug problems faster, what a variable actually is, and when it makes sense to raise a security policy exception.

We close with a reminder to lean into your unfair advantages and use what you have to move with confidence.

Timestamps:
00:00 - Welcome and disclaimer
02:13 - AI in housing, bias, and disparate impact
10:52 - Anthropic leaks, model hype, and trust concerns
19:24 - 401(k) rule changes, private markets, and retirement risk
28:24 - Why continuous admin or root access is dangerous
32:21 - What it means for data to be the new oil
39:55 - How great engineers debug problems faster
48:03 - What a variable is
51:55 - When to raise a security policy exception
57:34 - Q&A wrap-up
58:55 - Lean into your unfair advantages
1:02:21 - Birthday shoutouts and May paintball announcement
1:03:47 - Outro
 
#SoftwareSundays #AI #Housing #401k #CyberSecurity #SoftwareEngineering #TechEducation #Leadership #Data #Anthropic #RootAccess #Debugging #BuildLearnImpact #PrivateEquity

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

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

Transcript

SPEAKER_00 0:00

Welcome to Software Sundays Builders. This is a space where we have high-level conversations about technology and the impact that it has inside of our community. You'll be able to walk away with actionable information that will help you grow your income, become an owner inside of the digital society, and shape what happens next. If this is your first time tuning in, it is great to have you. You are in the right place. If you've been rocking with us for a minute, it's good to be back. Let's get into it. Before we jump in, do want to get a quick disclaimer. Software Sundays is for informational purposes only and it is not professional advice. The views expressed are my own or those of individuals quoted and do not represent the beliefs of Build Learn Impact or their affiliates. The topics that we discuss may or may not have a or apply to your specific situation. Please consult your own tax, business, or legal advisors before making any decisions based upon information you found in this show. That being said, if you like the news, if you like the information, let us know. If you have some information that you want to share, send it through. Let's work. So a lot of interesting things happened this week or going on at this current time. The housing industry is rapidly adopting AI for decision making with loans, leases, and pricing, while at the same time, regulatory safeguards are starting to be rolled back. And it's changing how discrimination is tested and defined. So since his inauguration, the Trump administration has sought to prevent the federal government from enforcing certain rules that are and have been created to limit the amount of discrimination inside of our infrastructure in our uh departments. One of those rules is the disparate impact method for identifying whether or not a policy or a tool or some process is discriminating against people. The difference between this disparate impact and blatant racism or, you know, applied with racism is the fact that it doesn't just get flagged when the intentions of the party making the decision or creating the tools are biased. It is based on the effect of those technologies and those systems. So even if the person creating the policy did not mean for the effect to be biased or negative against a specific group, they would still be liable for any types of bias and issues that happen based on the outcome created from that policy. So it was it was a and is a rule that would make it easier for people to basically try and sue on behalf of their uh discriminated characteristics. Uh with us getting rid of, or at least the the rule itself being not enforced as heavily in different departments like HUD and like the Consumer Financial Protection Board or Bureau, it's making it more difficult for people that have claims that have real outcomes that have shown and feel like discrimination to actually go in and get a decision in their favor from the courts. The interesting part about the fact that AI being flagged or highlighted in this report is the fact that the technology that is being used, the algorithms that predict a home's value or predict whether or not a renter will be able to make their payments, those algorithms are not new. The change I'm seeing is that the technology that runs, those algorithms are just becoming more common. They're becoming more accessible. And so as AI starts to become more widespread and the tools that power it become more accessible to more people, then you have more of the same results that you were seeing previously. Whereas in five, 10 years ago, you might have seen one or two organizations using these algorithms. Now you're seeing a hundred using the algorithms. And the problem is those algorithms may have been built with bias in the first place. When we think of AI, one of the major risks associated with using and deploying AI inside of real businesses and with real people is that all of the algorithms have been built at a time where we may or may not have been tracking the outcomes associated with the results of these algorithms. When you start to create new systems and really embed those same systems that haven't been proven to be unbiased into new systems that are faster and more scalable, then you start to see increasing effects and compounding effects of that same bias now for more people. So it's definitely something that needs to be addressed. It needs to be addressed by the developers that are building these systems, but it needs to be something that people and policymakers are keeping in mind to understand that this is not new. This thing has been going on for a while. It's just now we have different tools and features in place to potentially identify it a little better. So I think it's not a bad thing that we're using AI in housing or we're using AI in renting and making these different decisions. The suggestion I would give to people that are working in the mortgage industry or the uh residential uh realist rental industry, I would say is learn how the tools work and understand where the gaps lie. If you become complacent and assume that these tools have been built to work correctly or that they're always going to work the way you expect them to work, and that there is no risk to using them, you're going to start using them as if they are catch-alls and as if they don't have edge cases that really need to be uh deep dived into. The training is the gap here, in my opinion. The training is the thing that is missing when we start seeing a hundred different realtors or a hundred different property managers using the software that they they don't know how to use. So they don't understand how to check the results that they're getting. There are some screenings that can be done very easily with automation algorithms and AI. That's fine. That will at that will lower the amount of extra work that the property managers and these operators need to do to actually make sure they are running their business legally and in compliance and effectively. That's not a bad thing. But you have to have the ability and the awareness to know when you need to recheck the results, when you need to go back through your system and adjust something, or you know, have some type of way of handling exceptions that occur. If you don't have a way of handling those, then those same biases that we are trying to protect against are going to start showing up more and more often. And yes, the fact that the protections that should be in place to help combat the worst case effects of these algorithms, those being rolled back and repealed is not great. It's not a good direction to be moving into. But I can understand it may help the smaller landlord that is getting caught up inside of trials or lawsuits that they just did not understand because they didn't understand the compliance the way they're supposed to. So I feel like it might help both sides from a run-through standpoint if we just have better training, and from a legal compliance standpoint, if we just make sure that the people using the technology are aware of how to use it a little better. But the tools that have a technology available for smaller teams is the whole reason why AI and tech and automation is needed. When you're trying to compete against a corporate landlord that has hundreds, if not thousands, of people working to handle compliance, working to handle property management, tenant management. You have all of those systems already in place and built at somebody with the capital, with the experience. It's very difficult for somebody with one or two units or one or two-person team to be able to compete at the scale that's required to compete at, at the speed that you need, at the efficiency that you need. We really do need AI in all of these tools. So I don't think the direction is to blame AI for acting incorrectly. I think it's incredibly important for us to understand that yes, it was trained to act like this, but we have the ability to improve the training. We have the ability to test how it's working and then redeploy those systems across our society in a more equitable way. So it's definitely a story to me about education and making sure that the education is being disseminated more easily and more effectively than it is currently today. And some other news, Anthropic claims that their new AI model represents a significant upchange in capability. I personally think that this was a marketing ploy. But we shall see over the next few weeks and months uh what really comes across. But the could the company is suggesting that one of their recent leaks, well, they're suggesting that it was an unintended leak due to human error. I can believe that their source code being dropped last week or uh a few weeks ago was unintentional. They probably didn't want that to happen. But it does seem odd that two weeks in a row that there are two, I won't say significant, but two types of data leaks from their team. Either someone is not paying attention, which makes me not trust them all the way, or this is just a marketing ploy or a way for them to build hype about their products. Because inside of the documents that were quote unquote leaked, there were some plans about new models that were being deployed. Some of these new models are supposed to be significantly more expensive than existing models, as well as significantly better in terms of performance for cybersecurity as well as uh thinking and processing tasks. So if that's real, you know, it's coming very soon. And I'm not gonna say if it's real, I'm sure they have made incremental improvements to the model. I don't know how significant it is from a cost perspective or even from an efficiency perspective to say that it's worth you know being kept secret or it's this significant step change inside of uh their model capabilities. Like I don't know if it's all of that, especially because they also included in or as part of those leaked documents, it included a small rollout for the product. Like they had already planned on releasing the model to only a select number of potential customers, those being large enterprises. And I actually saw a story in the news recently that I'll say the news in Bloomberg recently, uh where I think the secretary of state, uh Scott Benson, I want to start a line on people or misputting their names, but uh he as well as some other members of the cabinet were suggesting to banks, US banks, to start using and playing around with this new model that's being released so that they can help more quickly identify uh their vulnerabilities and basically improve our financial uh global financial system by reducing the number of open vulnerabilities that are found on these systems. So if it's really that good, and that's why they're being recommended to banks, then that's cool. Kudos to the team. I know y'all have been working hard over there. I do, but it does seem to me just odd timing, and it just doesn't seem legitimate or authentic. It seems very much uh staged to just build hype. And that's one of the things that I think is worth just highlighting here is the fact that yes, AI is real, the benefits of AI is real, but there are plenty of products, tools, and teams that are claiming something that is not true or that is specifically done to generate hype. We have to understand we are still very early inside of this site, this current cycle of AI. There are still billions of dollars to be spent by the hardware providers, by the software providers, and by the new companies that are being developed. And everyone wants a little piece of that or a bigger piece of that than they currently have. So you have to be very mindful about the things that we see to understand when that's happening in front of you. So don't uh think that AI is not getting better, but don't think it's going to keep making very large changes over the next few months and weeks. Like it's we've kind of hit a plateau point. I'm not saying it's a significant plateau or that it won't make any changes or any improvements, but it's been mentioned. We've gone almost as far as we can from a just throw more data at the problem solution to improving these models. At this point, you need actual research to be done in the underlying algorithms that are used to train the models to make them faster, to make them smarter, and to just make them better. That can't be done quickly. That requires significant amounts of time. So, definitely something I'm keeping in mind. Uh Anthropic has their own like other challenges that are definitely top of mind or front of mind for me. I think this might just be a way for them to generate some of that billion dollars that they're probably gonna lose if they don't handle this situation with the Department of Defense and the Pentagon. Uh, and speaking of, I mentioned last week that the security risk label that Anthropic had been assigned had been removed, and that was not true. Uh, it seems at this point that the government-wide band has not been halted, or at least it's been halted government-wide inside of a California court. But the actual label that says Anthropic is a security risk, that has not that has been upheld by a federal appeals court a few days ago. So they still have a significant fight left to go against to actually be able to be usable by the US government, uh, by U.S. defense contractors, and to really help just fix their brand inside of the market. So it was actually interesting. I went through or briefly looked at the court documents for their case, Anthropics case, and they are suing everybody. They have half of the Trump administration cabinet on that defendant list, as well as entire U.S. departments, Department of Treasury, the Department of Defense. They are trying to get everybody. Now, I won't say to go down, no one's really gonna go down for it, but they are making as much noise as they can and I get it. The estimates is billions of dollars on the line if they don't get this handled, if they're not able to run their models inside of the government. Like that's everyone should know that the government is the biggest spender of money, not just on defense, but on housing, on everything. Like, government spends. They don't have the money most of the time, but they're gonna spend something. But if you lose access to that pipeline of funding, that is not great for a company that is very new, still hasn't gone IPO yet, uh, or still hasn't gone public, and is competing in a very capital-intensive market. So I know they are not playing around, and this is not the time for them to be losing out on money. So I really do feel like this original story about the new model is really just a ploy, just to get them back to where they need to be. And also, the US Department of Labor has proposed a rule that would allow 401k plans to include alternative assets such as private equity, private credit, real estate, and cryptocurrency inside of their portfolios. This is incredibly important for everyone who is nearing retirement or who is funding their retirement through some of these traditional plans through their employer. So, some highlights I think are worth mentioning is the fact that this move could give retail investors greater access to the high growth opportunities that accredited investors have had access to for years. That would be very good, right? Crypto has been one of the best, well I say crypto, Bitcoin has been one of the best all-time performing assets so far. Most private companies before they go IPO, that's where they make the most of their gains, right? Before the company goes public. By the time it reaches the public markets, a lot of those gains and that appreciation has already been realized by early investors. So there's a great possibility that with this, that would maybe decentralize and distribute some of the access and the benefits of that growing capital or that that growing capital appreciation. This is all good things. The risk is that if those fund managers decide to invest the 401k plans and these retirement plans into assets that become junk assets, then the public starts taking on greater risk than what they are kind of educated on taking. Right? Every investment into a startup is not going to be a unicorn. It's not going to be Stripe, it's not going to be uh, I'm saying Stripe, they're not even public land yet, but you know, it's not gonna be a SpaceX. Some of them will be your uh It what's a company that kind of failed? Uh Armada was um Sam Bakeman Freed, his company. That was a startup at some point. Uh there are plenty of startups that just didn't work out. I don't have to go into all their names, but basically, there are plenty of companies that just don't work out. Today, accredited investors are the ones that get access to those companies when they're very early. And that kind of keeps the risk inside of that specific group of people. When you start making it accessible to everyone, you start expanding the amount of risk that we are all under. So this could lead to issues such as the retirement accounts. If they if you make enough bad investments, there won't be enough money to actually pay out people during their retirement. If that happens, then we are, as a country, going to go into either a recession or significantly more inflation because we're gonna have to print a lot more debt to deal with those failures when they happen, to actually bail out those plans and these companies. So it's something that I can see both sides. One of the things for a private company is that they could get access to larger amounts of capital for expansion operations and acquisition. Over the last 10 years, 10 to 15 years, companies have been staying private longer. They have been delaying their initial public offerings because they've been able to get more access from the private markets through VCs, through private lending, and that has made them basically they're gonna grow as much as they can before they have to go into the publics and start dealing with you know government governance reporting from an SEC perspective. So this would actually increase the amount of gains that are happening inside of the pub the private market before we even get to the public market. Because one if there's more money to be raised, they're going to raise more of that money. So companies might stay private for longer. The opportunity I see for builders like yourself is that if more funding and capital becomes available in the private markets, we have to figure out how to create pathways that allow us to get access to that additional capital. I think the black community, black founders get less than 1% of the uh funding that is available in VC and uh these types of capital projects. So even if we don't get more than 1%, we would at least get a larger amount because the pie basically grew. We do need to deal with the issue of us getting access to more of the capital just like from percentage-wise to be more representative of our place inside of the market. But that's a holding up, that's a problem for yesterday. Right now, uh we gotta you know pick your private problems. But definitely an opportunity for founders to get some of that private access, that cap that access to the private capital. So it could be a win-win for everyone. It could be a little dangerous, especially short term, like right now, a few of the private lenders, private market uh companies like Blue Owl, they're having some significant issues. They actually limited the amount of people that can take their money out of their fund. And that makes sense, right? If you're if we're investing in something that is a capital-intensive multi-year project, you can't just be you can't just give me the hundred dollars today and think you're gonna get it back in a week or two. Those projects take years to actually complete. So I understand from a timing perspective, it's maybe just the timing was wrong. Not that they did they did something wrong, but it it doesn't make sense. If you just started the build-out or the if you set if you start the application in the US to build out a data center in January, you might not break ground until December. And depending on where you're at. So these projects take time, and that's the type of projects that these companies, that private equity is funding. So short-term liquidity risk or issues will probably rise. Uh and it's it's just my money, man. Is it's the finances, the money, the financial system. It's very difficult to predict to some people what is going to be required when. If you start making the capital more available in the private market, does that do anything to inflation? That might make it so that you need more retirement income. Or, right, there's other things and other levels that are moving at the same time. So definitely something I'm gonna keep in mind over the next couple of weeks and months, see what changes are happening and how uh things are developing. But we will definitely monitor the situation and keep you informed on the progress. But if you value the information that you have heard and received so far, please like, comment, and subscribe. We want to know what matters to you, and we want to help answer some of your questions to make sure we are hitting it right where you need it to be done. So drop your take inside of the comments and let us know. We're gonna get into our QA uh part of the show today.

SPEAKER_01 28:20

Why is continuous use of admin or root level access dangerous?

SPEAKER_00 28:27

So at a technical level, it increases the blast radius, the attack surface, and likelihood of failure inside of your system. When you think about root access, root access is top level, this is like god level power on your system. So every mistake that you make using an admin or root level account is going to be a final mistake. If you mess up, it there's no, there's usually not a way to roll back those changes. There's no one that can limit the scope of your mistake if you are the god level inside of that environment. So in a regulated environment or a regulated company, that is going to be a compliance failure. Because if you can't even distinguish between who made the change and why, that's going to be a problem. You could have someone deleting data or adding data that you don't even know who they are, why they did it, what authority they had to make these changes that you are seeing. And another issue is that when you build systems using root level or admin access, it creates a false sense of security. Because you can set security permissions that allow a bucket to talk to or an API to talk to a bucket inside of your environment that is not going to scale well when you get multiple buckets or you get multiple environments, or when you start to scale and grow your teams or projects, and having admin-level access that you'll eventually need to lock down is going to become a growing pain. It's going to be technical debt over the long term that you would rather just handle in the first place. You would rather use least privilege as early and often as possible so that when your systems grow, you know that the access that this application has is the right amount of access that it needs. If you are not thinking about that from an identity perspective, if you're not thinking about that from a data access perspective, if you're not thinking about that from a resource perspective, what services such as API or AI credits or APIs for third-party services can your application access? If you're not having a way to define that without just saying, oh, give them admin level access, you're not putting in more fine-grained controls, you are creating unnecessary risk for yourself. And it's going to bite you, bite you in the behind at some point. So when you're building anything, maybe not you know locally, locally, well, I'll say not locally, but a lot of people had some issues when they was running open claw locally with access to everything. God level in automation is kind of dangerous at some point. So you have to be careful. But when you're building things, you have to just be mindful of the repercussions of the access permissions that you give to identities on your system. Especially again, automated systems are going to do things very quickly. And if they're able to do them quickly, and they're using a high level of access, it's going to be very difficult to come back from that. So you know, be mindful.

SPEAKER_01 32:18

What does it mean for data to be the new oil?

SPEAKER_00 32:23

So data being the new oil is a metaphor that just implies that raw data is driving the modern economy. Versus in the 1900s, the oil industry was powering the industrial age. Today, most of the products that we use have been built on data, meaning the data is the most valuable part or the most valuable input to those products. If we think about social media and Facebook, the way that Facebook, Google, and those providers make money is through advertising. Advertising is a data product. And even AI, the fact that we have large language models, we have generative AI, these systems are built off of large repositories of data and information. The product itself needed the data to exist, to be available for it to be as good as it is today. And then we start building other products and services on top of it to drive the economy. AI driving the economy, advertising, driving e-commerce, and just buying profiles inside of every area from autos, uh vehicles to housing, everything is driven by advertising and search. So it's incredibly important for making sure the economy works today. But if you step back, if you start to the beginning, their data and oil are very similar because they can both be discovered and extracted from the source. For oil, the source is going to be rocks or underground, right? But for data, it's going to be people. It's going to be your health data, it's going to be your usage data, it's going to be how you use the products and services in the world around you. Both can be clean. Raw data and raw oil are going to be nearly useless for most applications. You don't do anything with it. But once you've cleaned it, pre-processed it, and stored it, then you can start to look at that data or that resource as something that can be useful in a specific use case. That is incredibly important to understand. Data is stored in databases, file systems, and these types of structures, while oil is stored in barrows. But you have to have access to that data in order to get the most value out of it. And that access can be managed a lot of different ways. And again, the data can be used. Like I mentioned, data being used to train AI models, but it's also been used to drive these products that we use, drive even marketplace apps. If you're using an Uber, it's a data product. Your data as a user is available from a you know where you are perspective, right? You need to arrive right now to go to this place. The data from the drivers are available because they can say, This is where I'm at, this is how much I'm willing to pay or get paid for this service. All Uber is doing is acting as a data collector and brokering that relationship to pass data between you both so y'all can actually go through with the transaction. Data is super valuable for everything that we use today. So you need to be aware of that. You need to understand how and why it's being valued. And so when I say data is the new oil, or yeah, data is the new oil, it's a new valuable resource. I want you to understand that the people who control these resources will dictate how it is used. So if you want to control the outputs created from your data, because it belongs to you at the end of the day, then you need to understand the processes and tools that go into creating these outcomes. So you need to learn SQL. SQL is the language of understanding and speaking about data. It's knowing what data sets you are referring to when you're speaking about a particular real world system or real world scenario. Having that language allows you to have conversations about how your data is being used, how it can be used for an application, and what it needs to actually be ready for a particular application. Learn Python, which is a language for manipulating data. Most AI apps and models have been built with a Python library in mind. Most processing is done through Python and using that language. People don't know how those algorithms work. But even if I gave you the source code for how an AI system worked or how the data was generated or how the outputs were generated, if you couldn't understand how to read that system and the rules that were basically being applied, then you are going to still not have anything you need to be able to advocate for yourself or even be able to make a change inside of that algorithm. So understand the language of manipulation of that data. And then learn what a database is. Learn the different types of databases and how they are used to store data efficiently and protect data because that's one of the major reasons we use databases. It's not just to store it reliably, which is important, because we're talking about thousands of terabytes of data for certain applications and certain teams and duplicated across environments. But we're also talking about how to make sure that that data in whether it's PII or PCI or some health other health type data is not being accessible by the wrong parties, that people are not being able to access data that they should not have access to or manipulate it to start causing problems from people in other areas of their life. So there are a lot of things to consider when we're thinking about data, but understand its value and understand the ecosystem that is built around it to drive the society that we currently live in today.

SPEAKER_01 39:52

How do great engineers debug problems faster than everyone else?

SPEAKER_00 39:57

So I want to highlight the fact that debugging is a skill. When they are figuring out how to debug a system, they need to understand that the process or the thing that is having the problem is not just this large thing. There are individual components inside of that system that are supposed to work in a certain way. If you can identify those individual components and decompose that system, then you have a much higher chance of identifying the root cause. Once you get the root cause, you can more easily test why that root cause or why that individual component is not working and behaving the way that you need it to work. And so great engineers need to also think like scientists. They need to be able to hypothesize, test, observe results, and then repeat until they are done. Repeat until the hypothesis that they came with, they came up with led to a result that they feel is satisfactory given the requirements that they have for that individual component. Great engineers are willing and able to go through those iterations, however many they take, to actually solve the problem and reach the results that they want. And in line with those iterations, is the fact that they operate or optimize for fast feedback. If you're going to be testing something and creating a thousand hypotheses and testing that a thousand times, you can't be waiting 10 minutes every time you make a change to see if it works. The time doesn't, it just doesn't work. So you have to figure out ways to run things and loops as quickly as possible. That could be running a project locally, that could be mocking out some dependencies so that you have stable inputs and outputs without having to start something locally or having to wait for some network request to or response to be applied. And you have to be able to log things as they are going through. You shouldn't have to wait until the end result to know that something went wrong. Especially if it's a long-running process. You should know as the system is going through, especially if you identified where the break happened, you should know and be able to check while it's running, okay, this it broke again. Let me go try something else. Or won't no. You should need to be able to have that ability and that observability into your system because it'll help you just run through your results faster. And that's what we need. We need speed. The great developers that can debug problems effectively and efficiently are going to focus on the speed of doing it, but not just doing it quickly for the point of doing it quickly. They focus on doing it quickly and doing it right. So you have to have your notes in place, you have to have a process, a structured process. Once you have that structured process, then you can go through the process as quickly as you need to do because you know it's going to work the same way every time. So focus on building those systems for yourself and your teams when you are debugging problems. So quick the story. So this week, I've been working on a batch processing system that is supposed to run every day around 8 a.m. And it relies on emails being sent from ServiceNow to updating some data inside of a SharePoint folder. And I received feedback a few days ago that we could improve the system by adding. Feature they wanted to add timestamping, so we this is a governance function, so we wanted to make sure that there was a clear record of history for what changes occurred inside of our system, inside of our inventory. So I could have spent multiple days making changes, waiting for the uh the email to be sent, like the trigger to start and batch that system to see how it worked. But if I did that, I would be working on this problem four weeks because I would have to wait every day, once a day, to know when something broke or when it was working the way it needed to work. So my first step was to isolate the system in a in an environment that I can control. So that could be logical by creating an entirely new environment or some type of cloud environment. It could be creating a separate folder, it could be doing it all locally. But you have to have that idea on I need to isolate this so I can run my feedback loops effectively. Then I was focusing on how to standardize my test cases, right? I told you that the system itself relies on getting some data from ServiceNow. ServiceNow has only been configured to send that data once a day. So I couldn't wait for that. So I had to, and I couldn't just every day um or just keep pulling that data, like during every run. So I pulled the data for a specific input, a specific day, that specific job, to make sure I had that available and created my test cases so I knew that if this is the input, this is the output I should always get. So everything in between should be where the changes are happening, where my logic is either adding something or removing something to make it work differently than expecting. And I kept meticulous logs throughout the process. Like I knew exactly which triggers I turned off in order to make my environment work and which ones needed to be turned back on before I could actually deploy this into the actual environment. I made sure I was logging the changes inside of the outputs that I was getting so that I could know, okay, this was this close to what I needed it to be, but it wasn't exactly right. Let me go make this change to see what that would be. So keeping those logs are going to be incredibly important for you when you're debugging and going through your iterations. Because it's really, you don't want to go so fast where you forget where you left off and you end up redoing work that you don't need to do because you'll waste resources, waste your time, but you'll not know, you don't want to get lost in the source trying to find the answer. You have to have some systems and tools in place to help you keep track of where you are throughout the process. But the main point is that great engineers don't just debug faster because they are smart. It's a skill, it's a learned skill that you can continuously improve. They debug faster because they have created systems for themselves and have practiced the discipline necessary to create these systems and run these systems as quickly as possible in any situation, in any scenario. So sometimes I'm curious what is one of the hardest problems that you've had to debug as a developer, whether it was in university or on a project with your job or on your startup. Like tell me what's what have you had to debug and how long has it taken? Drop those in the comments, please.

SPEAKER_01 47:59

What is a variable?

SPEAKER_00 48:05

So that might seem like a very uh low-level question. I'd say low level or uh early question to ask. But I think it's important to mention that most of us stop thinking about variables when we leave algebra class. But every app that you use, whether it's your banking app, Uber, DoorDash, they all use variables in the background to power the experience that you have. So it's very much worth understanding and knowing about. So a variable, you can think of it as a container, and it'll have three parts. It'll have a name, it'll have a type, and it'll have a value. That name is the label we call the box. Like it's a box, but we can call that box person, we can call that box dog, we can call that box school. And then it has a type. That type can be a string, it can be an integer, it can be a date, it can be an object, it can be anything we want to put inside of that container, but how we describe the type of that container, and then the value is the actual item inside of the container. If I put a dog named or a cat inside of the animal uh container, then the cat is the the item, the value. The item is the variable itself or the container, right? With something inside of it. So the variable name is just going to be how we refer to that piece of data in different parts of our system. You want to make sure that when you are building an application, you understand that the variable name has to be consistent. It has to be consistent, not just inside of the code, but inside of your mind, your mental model about what this code represents, what the system represents, what the process represents. If you start changing your assumptions on the naming of different things inside of your variable or inside of your algorithm, it's going to lead to confusion in different parts of your system. Where you might be referring to a variable somewhere higher here that is in this shape or this format or this type, but later down you're referring to it in a slightly different way. That could dramatically change the results and the output of the algorithms that you create. So being able to understand and track that naming is going to be incredibly useful. Not to mention that there are some naming conventions that are just best practices, whether you're going camel case, snake case, or some other uh formatting that you choose to consider. And it's important to understand that variables are creating the foundation of the systems that we create, right? If you create a system that relies on some variable, then that variable is going to be used to make different decisions. It's going to be used to store data, it's going to be used to power how that software thinks. So if you don't understand the variable that you're using, if you don't understand why we're using the variable or how it's being used, you don't understand the system. And again, we don't want to build systems that we do not understand. We want to understand them inside and out. We need to be able to explain them to ourselves and to others in a very clear and efficient manner. So make sure you understand your variables, make sure you're clear about how you're using a variable, and just understand your system. Tighten up. That's all.

SPEAKER_01 51:52

When should I raise an exception for a security policy?

SPEAKER_00 51:57

So you should raise a security policy exception when the policy cannot be followed, but you have a clear and defined business reason for why you need to be taking this action. A good security operation center is going to require you to defend every exception that you ask for. It's going to need to be deliberate, it's going to need to be documented, and it's going to be need to be risk aware. You can't just say I need to bypass this control because I want to bypass this control. We need to understand why you're asking for that. What makes your scenario, your use case, your business reason enough or per important enough to bypass the control, and what makes it so difficult for you not to be able to actually comply with the control? Most controls that are created by the organization have been written in such a way where it is it'll work for that business in their particular industry, in their particular use case. So if you are assuming that you don't need to follow this control, there needs to be some type of way to explain that. Because when we have a policy exception, it's not a way to just break a rule, just to break a rule. You still have to follow the governance regulations or the governance policies that are in place that someone is always held accountable for these changes. Someone is always going to be the owner, whether it's you, whether it's your your manager or the person or team beside you. Someone has to be accountable for the changes that are made in this system. So when we are making changes that do not align with the standards and the policy of the organization, then this is a big deal. So on my current team, I've been developing a system to automate some of our again, our governance reporting. We're pulling data from cyber systems or cybersecurity information systems and pushing that data into other systems that are more accessible to uh CIOs so that they can have weekly, monthly reports on the changes to their applications from a cybersecurity perspective. The tooling that has been made available to me has been blocked from doing the thing that I needed to do. Although it can do it, like the technical limitation is not there. It's a policy limitation that I'm running across. And so last week I actually raised a request, or I started the process of raising a request to get a policy bypass, or at least to find out if I could do it. And I had a manager, my manager basically advised me not to own that exception request. And it was interesting to me because at first I didn't understand it. I know we need to do this thing. Like I have an order to do this. We need this outcome. My personality, let's go get in. I'm gonna do it. I'm gonna make sure that the output that we need matches what the requirements were that were given to me. The challenge is that if I were to own this exception, I would be owning the responsibility for mitigating, or I would be owning the consequences if the risks that are you know potentially there are actually happen without having the responsibility or the authority to mitigate those risks. So if I make an exception on the software layer for a piece of heart for a hardware level uh group, then everyone who has access to the hardware would be able to access or you know make use of the exception that I created. And so it's like a boundary, security boundary problem where certain exceptions can't even be allowed because one, if you accept if you allow the exception here, what other systems would be able to bypass their control based on this exception here? That's a risk that most industries, most companies were not trying to take. And then two, if you decide that this is a risk worth taking, what secondary controls are you going to put in place to actually make sure that the worst does not happen? If you can't even lock down the system in the other boundaries that you know are going to be more important now that we move remove this layer, then we definitely can't do this. At this, you are of you, this box is hot. If we let this go, somebody going to jail. So it was funny to hear him kind of advise me against it. Especially when I was thinking, like, hey, we just gotta do this. We just need to make the app work. So I am grateful that he highlighted that to me, but it also makes me wonder, you know, what problems, or I would ask you, what problems are you creating bypasses for or to allow something to work without understanding the other secondary effects that will affect it. When we're talking about security and cybersecurity, there are so many things that rely on a defense-in-depth model that if you change even one layer in that ring, then you could be letting in a significant amount of vulnerabilities than or threats and risks than what you kind of were expecting. So something to keep in mind. I have some conversations scheduled later this week, this upcoming week, to actually you know talk a little bit more about this with the cybersecurity team. See probably we're not gonna be able to bypass the control, but see if there is another way of getting that data and accessing the data that doesn't rely on the tooling that we like I was told to use. So we'll figure it out. You know, it's all a learning experience and everything is iterative. So, you know, one door closes, figure out how to get over it, under it, or through it. And so that's all we had this week for QA. If you have any questions about any of the topics that we discussed, definitely put them inside of the comments. Uh share them on Instagram or anything like that. Let us know what your questions are. We can definitely dive deeper into any question that or topic that we discuss here. Uh, this spaces for you is to improve you and your skills inside of the industry. Some final thoughts before we leave is that I want you to lean into your unfair advantages. Everyone has an advantage that they have and only they have. And the most successful people are going to look at their advantage and make use of it without shame. That means even though everyone is great at something, they're not going to be great at everything. So you have to find the thing that you are great at and then go compete and lean on that thing entirely. It doesn't matter if someone else feels like you're being unfair because you are better at this thing than them and making them feel bad. It doesn't matter that this thing has made it so easy for you to do the thing that you're good at or do the thing that you wanted to do. Use it. There are plenty of people that are using their unfair advantage, and most people just call it discrimination. But you can't do anything about it because you're not going to stop them, they're not being stopped. So you have to go, use yours, whatever it may be, to actually make the best use of the situation. Me personally, I have an unfair advantage in the fact that I have no actual no chronic illnesses. So my unfair advantage is that I don't have to go into the office all the time because I have actual, uh I have an actual disability that makes it impossible for me to do certain things sometimes. So that's an advantage to me. I get to save more money not commuting. I get to save more time uh by, you know, that I could use to work and do other things. So it's an unfair advantage. It's not great, right? It's it's a thing that is mine because it's mine, but it is what I have. You have to use what you have. If you don't use the things that you have to your best ability, then someone is going to use the thing that they have to their best ability. And they're not going to feel bad about the fact that you are not making, like you're not competing with them in it in this area. So I want you to understand that. If you handicap yourself to make the people around you feel better, then y'all all gonna be average. And average people do not win championships. So if you are a winner and you are a builder, I want you to figure out what your advantage is, and it could feel like a disadvantage sometimes, and then you figure out how to reframe that, reshape that for you to work in your favor, and then you go abuse it, abuse it, no matter what they say. If you can use it, use it. Don't feel bad, don't be ashamed, don't slow down, do that. Uh, and that's all we have for today. Some quick shoutouts before we jump out, though. Uh happy birthday to my cousin Lynette. Uh I'm I'm not even gonna start getting into people with ages this year or this time of the year, but happy birthday to you. Uh, I hope you are feeling great. I hope you are feeling amazing, feeling uh lively, feeling great, feeling youthful, and that I respect the great. Let's you feel like an elder now. I respect the fact that you are an amazing elder and great person. So happy birthday to you. Happy birthday to my uncle Dante. Uh you are and have always been Unc. I don't know why you want to be called Unk now, more so, but happy birthday to you. Um you are an amazing man, amazing father, amazing person, and I hope you are feeling great, healthy, lively, all of that as well. And also, happy birthday to my cousin Mark, wherever you are at right now. I hope you are doing good, you and your lady, and yeah, yeah, everything's good for y'all. And uh some announcements for May. Yeah, we're gonna be doing a paint and bowl event. I've been sending it out, sharing information, or at least putting out feelers for everybody to see um, you know, interest, get interest for it. But I will be sending out those invitations uh later this week. Expect an RS or please give an RSVP by the end of this month. Ideally, want to see who we have coming, how we're gonna make this work, and let's make it happen. So, so everybody, happy Sunday. Enjoy your day. Hope your week goes great. I hope you are continuing to build and grow and develop in the way that is most impactful and interesting to you. I will see you all in the next episode. Peace out, my people.