NVIDIA’s AI Empire, Infrastructure Wars & Engineering Habits That Matter | Software Sundays

This week on Software Sundays, KD explores the global race to build AI infrastructure and why sovereign AI is becoming one of the biggest technology trends of the decade.

We begin with NVIDIA’s partnership to help build AI data centers in Indonesia and what it says about the growing demand for sovereign AI, digital infrastructure, and national technology independence. KD explains why today’s AI boom is really an infrastructure story involving chips, networking, power, and massive capital investment.

Next, we examine Google’s AI capacity crunch and why even the world’s largest cloud providers are struggling to keep up with demand. As AI adoption accelerates, engineers will increasingly need to think about AI cost optimization, token efficiency, and the business value behind every inference.

We also discuss Anthropic’s export restrictions on its newest AI models and why those decisions are pushing governments and allies to invest in domestic AI capabilities rather than relying on foreign providers.

In this week’s Q&A, KD answers questions about application logging, why individuals may benefit more than large corporations from AI, how to review pull requests effectively, common engineering habits that slow developers down, and why firewalls remain one of the most important security controls in modern systems.

CHAPTERS:
00:00 Introduction to Software Sundays
00:30 NVIDIA's Global AI Expansion
04:04 The Evolution of Data Centers
07:03 AI Infrastructure Challenges
11:19 The Token Economy in AI
16:06 Sovereign AI and Global Policies
22:14 The Importance of Digital Sovereignty
25:59 Q&A: Application Logging Best Practices
32:25 Opportunities for Individuals in the AI Era
38:31 Best Practices for Reviewing Pull Requests
45:00 Bad Engineering Habits
52:02 The Role of Firewalls in Network Security


Join BLI University:
https://discord.gg/jpJHGq6kgS

Connect with Build Learn Impact:
Instagram → https://www.instagram.com/build.learn.impact 
Substack → https://buildlearnimpact.substack.com

Connect with Kevin Dowdy:
Instagram → https://www.instagram.com/mrkevindowdy 
LinkedIn → https://www.linkedin.com/in/kevinldowdy 
Substack → https://substack.com/@kevinldowdy 
GitHub → https://github.com/kevindowdy

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

#SoftwareSundays #AI #NVIDIA #SovereignAI #Anthropic #CloudComputing #CyberSecurity #SoftwareEngineering #DataCenters #Cloud #Firewalls #Engineering #BuildLearnImpact

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

Transcript

SPEAKER_01 0:00

What's going on, builders? Welcome to Software Sundays. 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 to make sure that you have the tools and the resources that you need in order to grow your income, become an owner, and help shape what happens next. So if 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. Let's get into it. First off, this week on the news, I want to talk about the fact that NVIDIA is partnering with an AI startup to build data centers in Indonesia. So this is another uh example of sovereign AI, sovereign data centers becoming a thing that almost every country is taking more seriously. Every nation is looking for ways to expand their access to AI, their access to digital infrastructure beyond just relying on the US and China. Even understanding that China is considered one of the uh like the other side, even for some of our uh partners, they still have a significant amount of uh what do you call it? There's still a challenge with just knowing whether you're gonna get your resources from the US or China. Um this is also another example of NVIDIA just on a tear. They've been making deals with every country and every company that they can to get their resources, their GPUs deployed into these next uh next generation data centers. One of the things, even thinking about that, is a data center is definitely a capital intensive uh project to even undertake to build. But once NVIDIA gets those contracts, once they're already in the door, it becomes even more sticky for their uh for their products and their services. Because not only do they you know provide the initial upfront GPU, setting up the server, setting up the networking, even setting up some of the cables. They also get that long tail uh service uh support. So whenever there's an issue, there's a contract that NVIDIA gets for the next five years or however long that term may be between these two companies that are using them. But it's something that you can see that NVIDIA is not only moving quickly to get a foothold into these data centers, they're making sure that they're going to be there for the next five to ten years, anyway. But it's definitely very interesting just to see how many nations are saying we can't continue to have our AI being owned by the US, or we can't continue to have our industries, whether it's your banking uh companies, your healthcare companies, your government, like your actual government services, being reliant on a model that is hosted in the US. So the major shift that we're seeing is they want to have these models or have at least have infrastructure to support the running of these models inside of their own country that they can have their own privacy laws on that data, that they can have whatever other regulations they want to implement, whether it's it's not just taxing the AI, right? It's sometimes just making sure that the country that is that the data is hosted in doesn't have any laws or policies that might conflict with the country that is using those services. So it's something to keep in mind. But another interesting thing about this story was the fact that the company that's leading the actual project delivery, right, um the company that's going to be setting up that data center, they're called Fermis, and they're actually based out of Australia and originally was part of the Bitcoin wave. They were a Bitcoin miner, and so it's very cool to see that some of the skills that in the I'll say the maybe the partnerships, the experiences that they got from deploying and setting up Bitcoin mining operations, so setting up those servers, setting up the networking. Uh, you know, that skill translated very nicely into the AI world that we're in today because those same resources are required. You still need to set up a lot of servers, you still need to understand networking to orchestrate multiple VMs, multiple nodes across a network, whether it's a local network or a more wider area network. So it's very cool to see that, you know, even though the time of Bitcoin, like let's say time of Bitcoin is still here, but even though it's not so much the main thing driving the economy or driving growth right now, there's still ways that you can benefit from that technical skill that was gained in a previous era. So something to keep in mind with any builder, like whatever you're building, the skills that you gain while you're building it, they don't just go away because the environment changed. They don't just go away because something you know got harder. A lot of those skills are transferable, especially from a coding and software understanding perspective. You understand technology architecture, then that architecture doesn't go away even if another abstraction is placed on top of it. So AI is just another abstraction, but it still uses the same underlying infrastructure being data centers, being networking, being being computers. So think about that today. Like what other investments are being made from an infrastructure side that's primarily driven by AI adoption, right? These data centers are primarily driven by an increase in the amount of AI being deployed. But those same data centers are not only going to be used for AI, they're going to be used for digital twins, they're going to be used for self-driving vehicles, they're going to be used for banking services. Like there are other ways to use this AI or these data center resources that will extend beyond just the initial height of AI and everyone getting their own model. Additionally, AI infrastructure constraints are growing, especially as Google caps Meta's use of Gemini AI LLM. So this is another example of the fact that we don't have quite enough compute resources yet. Even though countries and companies are moving as quickly as they can to build out new data centers, to build out the infrastructure that we need to run these models and train these models. It's just not fast enough yet. The adoption of AI, the number of companies that are trying and actually actively deploying AI and LLMs inside of their architecture, inside of their services and products, that's moving more quickly than we can purchase the land, then we can get the energy, can then we can actually build out the server, right? There's a physical constraint to the software problem of just hosting an LLM. So multiple companies are running into that issue today. I think that's one of the reasons why SpaceX is currently worth as much as it is. It's not the space exploration part that makes them so valuable. It's all of the compute that they were able to sell to the AI companies that really are in a bind. They're in a bind for the power, they're in the bind for the compute right now. So this is the perfect time for them to take advantage of that window of opportunity. But other companies are having those same challenges. We're looking at a hyperscaler, right? This is Google. They are one of the big three cloud service providers. And they are saying we don't have enough AI, one, two, we don't have enough compute to satisfy our current need and our customers. So that's one of those, like, if I only have one chip and I have to use it to either run my services and my products or run your services and your products. Before I start saying, all right, how do I give more, make it available to others? Right. Even the concept of the cloud. It's the point is if this one provider can purchase enough compute and spend enough capital up front to get better economies of scale, right? To get a lower uh cost per chip or lower cost per gigawatt, whatever it may be. If they can spend that, then they can give and charge a premium on the excess that they give to customers for renting out that excess capacity. If there actually is no excess capacity, then there that doesn't work. So even going back to the first story, there is a race to continue to build more of these data centers, but the race is driven by the fact that even the largest providers don't have enough capacity. There, the demand is more than anyone, I think, expected at this point. I won't even say more than they expected. People and companies have been saying, like even this year, over I think $700 billion is going to be spent in 2026 alone, or plan to be spent in 2026 alone between different hyperscalers to actually build out their data center. That's a known problem that you know they're looking to solve. But it's not a quick problem that you can solve. There are again that physical uh challenge getting the actual materials to the site, building it out, skills, the labor, the um machines necessary, that is not an easy problem to solve. That that's a challenging logistics problem that takes time. But even if you think about the like so I'll say that capacity issue coupled with the growing demand is leading to another challenge, right? A few months ago, there was a goal, like everyone was token maxing. That was a term in Silicon Valley, that was a term in the tech industry. Use as many tokens as you can. And of course, NVIDIA, uh, the CEO, right, Mr. Jensen Wong, uh, he he was definitely driving. I I personally think that's one of those things that if you're selling the tokens, it is in your best interest to get more people to use those tokens, right? That that was a thing. It makes sense. From a customer perspective, like Meta, Amazon, I think Uber, they had leaderboards for how many tokens they were using. From that perspective, it doesn't make that much sense when you start thinking about like how does this scale? What is the point of using so many tokens if we don't actually get any business value? We're coming to the point where that business value is more important now, right? If you going back to Meta now has a limited amount of resources, a limited amount of capacity of this Gemini model that they can use. So they're going to have to be very selective about how they use that capacity. Maybe we can't use it for just some uh you know, like POCs that we don't know how it's going to benefit the business. Maybe we don't use it for internal tools, maybe we use our own local LLMs or their own uh llama models for internal tools, but then use Gemini models for their customer-facing services. Like you have to be very selective about how you deploy those technology services. But it makes me think about back in the early days of the cloud when it was okay for it was okay, but you would have less controls in place for developers spinning up new resources. You might have a developer with full access to the AWS account, spinning up VMs, uh creating S3 buckets, and kind of playing around with the resources, because that there's a time when a lot of these services are gonna be subsidized to actually gain adoption, right? To generate more interest, to allow people to play with it. Once you've played with it enough and you know what works, you have to start stamping down some of that use because now it becomes a like an operational problem. Like if you continue to just spend on tokens without understanding the ROI, without having a clear reason of doing it, like does it increase revenue? Does it decrease spending? If you don't have that actually uh decided before you do the spend, and you continue to make that spend a a goal for your developers for different engineers across your team, then you just you're more likely to burn out your budget more quickly. So I'm expecting that we start seeing a similar trend to FinOps or for AI, AI resources. The same thing, right? It's how do you use the resources, the digital services that you consume more economically? How do you make sure that we're not using more tokens that we need just because the context window has expanded? Is there a way to cache some of these responses, right? Can we set up a cache in place so we don't have to use that uh those tokens for this particular request? Is there a way to like is there a way to use more traditional architecture to do some part and then leave the LLM reasoning and token use to a very specific use case? Like those types of problems and challenges are going to be more important for engineers or the so-called AI engineers to understand from a business perspective because the business is not going to continue spending on things that are more cost than the what they're worth. So something keep in mind uh as you're thinking about your next projects, your current projects, like just be mindful about what resources you're using because it goes back to the business at the end of the day, it has to be a business-driven reason for everything. And then uh one of the other reasons for why sovereign AI and uh the accompanying policies are so important is the fact that Anthropic's crackdown sets off uh alarms for even US allies. So recently I mentioned that the US government decided to lock down Anthropic's latest model, Fable Five and Mythos, for foreign national users. Basically, the uh the goal is to make sure that no one outside of the US, whether they're living in the US, but from another country or directly inside of another country, none of them can actually use the latest models, the most advanced model. Uh the fear was that the model, even though it had some safeguards in place, that there was a way to jailbreak it. There's a way to get around some of the safeguards that Anthropic placed to limit the destructive capabilities of these models.

SPEAKER_00 17:33

That was the goal to get well, that was the fear.

SPEAKER_01 17:38

Um it didn't it looks like that fear has been kind of addressed in the meantime, like slightly. Uh some companies have been allowed to use MyFOS again. But uh, let me backtrack for a moment. The the initial appeal, right, from the US government was you know, make sure that foreign nationals can't use it. That doesn't work for a company that only collects your name and your email address. There's no way for them to know if you are actually a foreign national. So they had to just shut it down completely to make sure that they could comply with that requirement. I did see some stories that like allegedly anthropic might uh look to start collecting IDs from users, like your you know, full legal name, address, all of these things from users before you can use the latest models. I have to do some more research into that, but uh I'll definitely uh bring that up next week uh as more information comes out. But even partners of the US, like the EU, uh like Taiwan, like they are on that list of foreign nationals that cannot use the model, that cannot use the latest model. And as an ally of a country, imagine your ally knowing that you are dependent on them to provide this service, decides to not give you access to that technology. That is almost like a slap in the face in a way, because now you were like, there's a number of negotiations going on right now for how the EU and the US can partner to go against China. That's like on one thing from uh from like the rare earth minerals side. They're really trying to uh not be so dependent on China for those required materials. But from the software layer, you're still the EU being they're still very dependent on the US for cloud services, for AI, for chips, right? Nvidia still is the largest or provider of GPUs, which are the most common chips for running AI infrastructure or AI workloads, right? You're still very dependent on the US, and so from their perspective, it's like we cannot continue to be this dependent, especially when that country is deciding to you know give and take so quickly, all right? Like within three days of the model being released, that directive can came out. So now no one can use it. Imagine if your banks, if your healthcare companies, if your government uh uh offices are relying on this service and they decide to shut it off one day. That is incredibly dangerous. Like you can really that type of dependency on a nation that you have no control over is not a dependency that I think anyone in the government offices of the EU or any of their member states actually wants to be uh involved in. But it's definitely leading to more conversation in these companies and other country companies, uh countries, excuse me, uh for basically what is actually the investment goal. Like what are they investing in and why should they be investing in? Right now so much of their dependencies are outside of the US or outside of their country in the US or even in China. They're trying to invest inside of the talent in the companies internally to actually get that capacity, that service available from within their own nation. So I mentioned before that I expect to see more companies inside of the EU hiring and you know sharing their knowledge, training people, building that capacity, because at the rate this AI uh race is going, it does not seem likely that the latest models, the latest uh yeah, the latest technologies from these AI labs are going to be uh available outside of the US for a long time. It seems like that edge is looking to be held on to for as long as possible by not even exporting. Like it's very interesting to me that we have export controls on software. Again, I I had not thought that was a thing. And I guess that's the same as any other intellectual property, maybe. Maybe that's the thing. Like, um, I I just thought export controls were more of a physical thing. You don't ship weapons to a country, or you don't ship certain vehicles, or you don't ship, you know, whatever, like that physical thing. To see that software has been given the same uh classification as some of these other things that I just mentioned is very interesting. Because it like how important is this software for the government to say, nah, we can't let it go. But again, it it is just as important maybe as uh you know missile planes or nuclear power plane planes, like that type of intellectual property is not something that you easily share with your with everyone. So I kind of get it from that perspective, but definitely something to keep in mind for everyone, and the thing that I'm seeing that I want you builders to understand and be familiar with is that sovereignty in the digital age looks like a lot of things, it looks like chips, it looks like AI, it looks like energy, but it looks and is very important for you to invest inside of the space and to invest inside of these things, like invest time, invest your energy, invest uh you know, money, whatever it takes to understand how this ecosystem is growing and how it's like what it's built off of. It's something that you don't want to not have any other option outside of the mainstream options, right? It's okay to not rely 100% on these technologies, not give away all of your thinking capacity, right, to these models because who knows if that model will be available in six months, or and I say available, it might even be available. What if the cost for it becomes more than you can afford? So, do you lose access to the thing that you need because you kind of you already tried to delegate it to this technology, to this third party that you really had no business delegating it to? So think about your sovereignty in this digital age, it's not something that you want to give away too easily and too freely. But if you want to go deeper into any of these topics, uh join BLI University. We are going every week into cybersecurity, AI, and how you can use these concepts to uh create opportunities for you and your family. So uh you know, join and have a conversation with the builders that are leading that revolution, and we'd love to see you inside of the room. So we're gonna jump into the QA for this week. What information should you include inside of your application log? So your application logs are being generated directly by the app or service that you are running. Whether it's an API, whether it's a uh web app, whether it's a uh batch script, that application is doing something, and it's very important for you to know what that thing is doing and how far it got along that process, right? Let's say the specific workflow that this service is responsible for orchestrating or completing. Let's say it only got 60% of the way done. You need to know how far it got, you need to know where it stopped because you might need to restart it from where it was, or you might need to know can you restart it? Like maybe you can't restart it because it got past a point of no return. So these are things that you need to be logging. You need to be logging the uh yeah, how far it got. But think about logs as a tool for debugging and also for security monitoring. Now, you may not have or your security team may not actually be using the same logs that you're using to debug whether your application is working today or whether it was working uh 24 hours ago. But they are still using those logs inside of a different system, right? Like you might have your application uh send the logs to Datadog, and then from Datadog, they're sent to Splunk or whatever scene that your team uses for actual security monitoring for analysis, there, right? So you need to have a way of distinguishing between a log that is useful for security and a log that is useful for uh the application itself for like runtime knowing uh the performance of the application. Two different things for the security aspect, definitely speak to your SOC, uh your security operations center to see what type of information they need to create analysis or to analyze the logs to see if there's an active attack, like they need to have specific information and they might want it in a specific format. Uh so figure out how to partner with them to get that format in the way that they need it for your debugging purposes and troubleshooting your application. It is best to not log everything, right? You don't want to just be putting uh certain data into your logs, right? So anything that is going to raise a flag for compliance, like PCI information or like your card information, like password, like PII, something about your specific users that is private information, you don't want to put that in the logs ever. But you may need to log certain activities for audit purposes that individual people do. And whether or not you're putting them inside of the application logs or actually logging them and saving them inside of a database that has its own controls in place, that's a business decision. You can decide which one is most appropriate for your use case. But certain things have to be logged, and certain things you really do not want to log. Uh, but remember that logs can be expensive. The more you log, the more information that you're saving, uh, you're gonna start getting costs for that. Even if you're using uh cloud cloud watch and you're saving your application logs inside of a log group, that log group is really just a S3 bucket at the end of the day, right? It's storage that you're paying for. Now, if you're using some other uh solution like Datadog or uh Dynatrace, they're also going to charge you for logs based on the amount of storage that you're saving, but also for the amount of data that you're transferring either to their system or out of their system. Again, there might be multiple uh locations where these logs are being sent to. So be very careful and mindful about that. Uh even from a uh storage times perspective. Do you need logs for your application from three months ago? Probably not. If if it didn't break then, you should know it didn't break. So you might you don't need those for your application security or your application uh logging perspective. Now your security team might store those logs indefinitely in case they discover some type of attack had been going on, but you have to be mindful that you may not want to duplicate those logs if you don't need to inside of your system. Then even considering the security of logs, like certain logs need to be stored in a secure fashion. You know, I mentioned some things that are for audit purposes. Uh, you want to make sure that those logs are tamper proof or and they're also secure from you know unauthorized access. You have to think about a lot of things when you're saving data, even logging data, because it can be used against you if you handle it the wrong way. And then why might the biggest winners of the AI era be individuals rather than corporations? So, from my perspective, there are more opportunities for small players to create wealth because they have access to better tools today. Ten years ago and beyond, the amount of people that you needed to do certain things was greater. You needed more teams, or you needed larger teams, you needed more uh expertise because there was just so much to do and it had to get done. Today, a lot of that work can be automated. And I'm not saying perfectly, but it can be uh delegated to a much smaller team that can get a significant way across than they could have before some of these tools existed. With that being said, they also have access potentially to the playbook that the larger team ran when they had to do it more manually with that larger team. So if you're looking at that current player and saying, hey, this is what you did to make it work with these people, but I have to make it work now today in this environment with more tools available to me, with a smaller team, maybe, potentially. I can imagine that there is a there's an edge that that individual or that smaller team gets because they're able to learn and study the people that are already in place, that are already doing it. And again, they have less overhead now to embrace and adopt tools available to them. Right? Additionally, there are some laws and regulations that impact enterprises and large organizations more heavily because of the footprint that they have, because of the exposure that that business or that enterprise might have on other uh partners inside of the ecosystem. So those same laws don't always apply to individuals, so there's an opportunity there as well. You can do a lot that is not bad for you to do because they're not really in the spotlight. Now, when you get into that spotlight, you have to be able to uh adjust rapidly, right? The things that you do from a risk or the the risk calculation you make when you have a million dollars under management is different than the risk calculation that you make when you have a hundred billion, right? So you have to be mindful when you cross certain thresholds that now some of these regulations might apply to you. Now some of these requirements might be important for you to adopt and implement. But for a lot of smaller individuals and smaller teams, you don't have to think about that so early, but you get the benefit of having tools that can actually scale to get you to that place much faster. So I think again, there's a lot of benefit there. Um I've mentioned, but that's from like a business perspective, even if we thought about personally in your life, the amount of complexity involved in enterprise workloads and enterprise processes exists because there are so many people, so many layers, so many teams, and so many hoops that sometimes need to be adjunked through. When we're talking about a family or an individual just living their life, having access to the same tools, but having not nearly as much complexity, the amount of solutions that you can deploy in your own life is like exceptional, unbelievable almost, incredible, and that's a that's a blessing, bro. Like having a computer that you can use to uh let's say have let's say you build an app today to manage the inventory inside of your own home, and that inventory management system that you have is nearly free because you used AI to build it, and it's the data storage for it is super cheap because you're using uh you know consumer grade technology, right? You're using Google Drive to store any of the files, or you're using Google Sheets to store your tables, right? That type of access to the technology, but also having uh the ability to run AI through your inventory to let you know uh or give you notifications when you're low on something, and you can use it to optimize maybe your purchasing or your grocery shopping. Like the things that you can do as an individual are crazy and crazy cool for real. So that benefit makes your life easier, it gives you more time to either focus on your craft, focus on your business, focus on your family, whatever the thing is that you want to focus on. Having AI automation, these tools in place frees you up to do more of that, and that's something that the larger organizations, the larger businesses, they can't and they probably shouldn't move so quickly to do that.

SPEAKER_00 38:31

What should I do when reviewing a pull request? So just a little background your pull request is going to be a request that is made from someone who wants to make a change to your project.

SPEAKER_01 38:52

Now, if you might make a pull request if it's even a single person working on the project, because you want to have an organized way of reviewing that change. Change management is a thing to consider. Uh, but especially if you're working with multiple developers or you're working in a team, you want to have that change management process uh working in a way that's reliable, that everyone across the team can be assured that the change that is being uh suggested is the best change that is needed. It and it works based on or works according to the way it's supposed to work. So one of the things to think about when you're reviewing a pull request is to review the issue or the task that that pull request was designed to solve, right? So operational maturity for any software team means that you have defined processes for getting information across the finish line. The first stage in any type of change request or change that needs to be made is a change request, is a ticket, is some type of documented information or documented note that says this change was requested by this person on this date for this reason. Now, when you take that change request or that ticket and then create a task in your team's board, in your team's project management software, whatever you use, that's all connected, right? You know, hey, we're making this change because of this request from this client, or because of this performance issue we noticed from the team or whatever it may be. We're making this change because of this, and then now you have that context included inside of your task, and then that task is used to drive any code changes you need to make. So that pull request should include as much information as possible from the task, to even be linked to the task, so you can always go back to it if necessary to get that additional content, maybe other conversations that were uh had that didn't involve the code necessarily. So always review that initial task, always review the thing that prompted this change before you even get into reviewing the code for the chain itself. And then in an organization that has mature CICD processes, that has a scanning in place on their pull request, that has a testing coverage calculation that is building and even running automated tests on their pull requests. A very easy thing you can do is just confirm that all of those builds ran successfully, right? That the scanning coverage was what it needs to be, was according to the standard, that the tests all passed, that the application itself was able to build inside of the environment, right? Those are very simple things you can do to make sure that the code reaches the quality that your team needs and what you're looking for. And then you should always try to run and deploy that code, right? You should try to make sure that it works locally or inside of the development environment, right? Wherever you can run it live to see how the actual change affects any other systems, or even actually running through a test, like if it's supposed to be a new button, run the application, see what the button looks like, see what it does, if it's supposed to be a change in a flow to uh maybe retry if a service goes down or some dependency goes down. Try to mock out what happens when that dependency is down, see if the system, this new change, actually retries the way you think it's supposed to. And if that all works inside of either your local environment or your development environment, then feel free to mark that code as good. But don't just say looks good to me because you don't really want to go through the process of reviewing it, right? A peer review, a pull request merge or a pull request uh review is really the last line of defense. Between a bug and production. So as a developer on the team, as an engineer, whether you're a junior, uh senior, or a lead on that team, it's your responsibility to make sure that that code actually does what it needs to do, and nothing that it doesn't need to do. So you have to be able to use your uh review very wisely.

SPEAKER_00 44:32

What are three bad engineering habits?

SPEAKER_01 44:36

So, you know what grinds my gears with engineers is when they don't document anything, they don't document the change that they need to have, like even going back to a PR. A good team will require a PR to have a change log message included, also. But that's neither here nor there. That is a standard that your team should apply. They don't need to, but at least documenting and why this change was done, what tests were ran to validate that this change worked. Like if you're the person that reviewed the PR, if you're the person that uh made the change, do you have any type of testing uh documented to say this is what I did to validate that this works? That's one no no the flag, uh no documentation, not having any type of information that a human can use to understand where we are. It's one going to just cause confusion later because we're gonna get to the place where a bunch of things are inside of the code that we don't actually know why they're there, they're just there at this point, and there's no reason, but because it works, we can't remove it. So, you know, if it's if anything broke, don't fix it. We don't ever want to be in that situation as engineers working on products because eventually you won't be there. The people that worked on it won't be there. That knowledge that they had about why they did this thing, it won't exist on the team, and then everyone who inherits that project afterwards is going to have a very difficult time making sense of what they're looking at, and then no test.

SPEAKER_00 46:32

That's another no-no.

SPEAKER_01 46:34

We don't want we don't want to have any code that cannot be tested. We need to know what does a good result or a good run of this code look like. We need to know the input that you use as well as the output to expect, so that we can run the code, whether it's it's today or six months from now, and know that this code still works the same way because we're still seeing the same results, right? So not having any test, even if it's a manual test, even if it's just a uh run book that you can give to someone and say, This is how you test this code, and it has some explanations on you know where you get the data, what it needs to look like, uh, what the output needs to look like, how to run, or you should have some how to run the code in a different like in your readme, but having some information that someone can use to verify that the application is working the way it needs to work. Super important. See a lot of developers miss that. And I'm not saying uh you have to adopt test-driven development, you don't have to start with the test, like however you create your test or the order at which you create your test, that's a that you can figure that out best for you, how that works best for you. But you have to have some type of test in place at at some point at all. Like you should know uh the test coverage for your applications, you should know uh what good looks like when it runs properly, and you should have a lot of those resources prepared so that someone can continue to test that it works over time, right? Uh regression testing is a thing for a reason. There are times where you fix a bug in January, and then three months later, that bug came back, and you should have a test to validate when that bug came back, you should have a test to know that it's fixed again, right? Like the test should never go away, even if we fix the problem. We should just have a green test, it should just be working because we are testing that it works and it was fixed. And then another, probably the most uh dangerous, if I want to be so dramatic, uh bad engineering habit that a lot of junior developers uh find themselves in is jumping into code without creating a plan.

SPEAKER_00 49:23

So when you jump into the code, this is one of the reasons why there will be no documentation, or while there'll be no test, you're jumping into something that is not designed at all.

SPEAKER_01 49:42

Like you're just assuming that the initial information that you had is all you need. You didn't create a plan, you don't know uh you know the direction that you're going to go. You're just going, you're just saying, I'm gonna just do this thing and hope for the best. And with AI, you're probably gonna get very far very quickly, but that distance that you went in, or that direction that you went in could be completely wrong if you did not come up with a good plan, if you didn't connect with the rest of your team to make sure you had under all of the content, if you did not explore some of the trade-offs that you're gonna make with a particular situation or particular solution. So try your best not to jump into any coding without a plan. And now that's not to say if there's something broken that you don't move quickly, right? But even having a rollback strategy in place is the plan that you have so that when something goes wrong, you know how to move quickly to the right, uh, so things working again properly. That's the plan, that's a strategy. Like going into anything without a strategy or a plan or an idea of what the next step will be is going to be an issue for you and everyone else who works with you because all you're gonna be doing is fighting fire, what you're gonna be doing is responding to things versus making things happen, and that's not what engineering is. Engineering is architecting, architecting is designing, is planning, is making things work given specific constraints and clear goals. So make sure you have all of that before you jump into any code because AI will tell you what it thinks it needs to do, but you are the one who needs to know what it needs to do.

SPEAKER_00 51:48

So good engineers don't just write code, they build habits that allow that code to be reliable, consistently, and effortlessly. Why should I use a firewall?

SPEAKER_01 52:04

So a firewall is one of the first security controls that you can implement to control what type of traffic your network allows. And that network could be well, that traffic could be that to the full network, or that traffic could be to a specific device or a specific host, right? There are different types of firewalls. You might have a firewall that is host-based, which is protecting that single device or that single endpoint, whether it's a laptop or a specific server, but you have network-based firewalls, which are in place between the subnet or that local that uh internal network and then the public gateway, and they're going to control the network requests that get through to your network, right? You might put a network firewall in place to block all traffic that you know doesn't have a lot of