Software Sundays

American Productivity, Big Tech’s Spending Problem & Why Human Engineers Still Matter | SS #38

• Kevin Dowdy

Share episode

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 54:52

This week on Software Sundays, KD breaks down why American workers are becoming more productive, what is actually driving those gains, and why the biggest impact from artificial intelligence may still be several years away.

We start with the relationship between productivity, quality, cloud computing, remote work, and the tools that have changed how modern teams operate. KD explains why businesses will continue expecting employees and engineers to produce more with fewer resources—and what builders must do to remain competitive.

Then, we examine the growing pressure on Big Tech to justify massive AI investments. KD discusses the disconnect between Wall Street’s expectations, current model capabilities, data-center restrictions, rising infrastructure costs, and the long-term value companies must eventually prove.

We also explore Anthropic’s discussion of AI-assisted code migrations and what the Bun migration reveals about the future of software engineering. AI can help teams write and transform code faster, but experienced engineers are still responsible for planning, testing, business alignment, risk management, and delivering outcomes that stakeholders can trust.

In this episode’s Q&A, KD explains why developers should keep their branches current, when to involve IT or cybersecurity, how to determine whether a certification is worth pursuing, three practical ways to reduce cloud spending, and why planned breaks are essential for maintaining high-quality work.

We close with a reminder to remain teachable, build strong relationships with people you can learn from, and invest in the skills that allow you to move faster without sacrificing quality.

Chapters:

00:00 Introduction to the series and today's focus on tech and community

00:27 US labor productivity has been increasing for six years

00:58 Defining productivity: output over input

01:54 The importance of quality alongside productivity

02:53 Technological changes enabling productivity gains

04:09 AI's current role in productivity and future potential

06:29 The build-out phase of AI technology and its implications

07:55 The competitive landscape and continuous improvement

08:49 Mastering tools to increase efficiency

09:33 Investor expectations vs. actual AI capabilities

11:53 Regulation and its impact on AI development

13:07 The long-term value of AI investments

16:11 Efficiency in cloud resource management and FinOps

17:38 Code migration projects and engineering leadership

20:00 The irreplaceable role of human engineers

21:38 Leading with AI: decision-making and trust

22:58 Developing skills for increased productivity

23:55 Join BLI University for hands-on learning

24:59 Weekly engineering tip: keep branches current

27:27 The importance of early testing and pushing code

29:39 When to consult cybersecurity and IT

32:36 Using approved repositories and managing supply chain risks

35:37 Balancing security and innovation in development

36:00 The value of certifications and continuous learning

38:21 The role of certifications in career advancement

40:20 Reducing cloud costs through resource management

44:15 Using cloud provider tools for cost estimation

46:44 The importance of scheduled breaks and self-care

51:06 Building relationships and mentorship in tech

52:57 Final thoughts and upcoming plans


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

Connect with Build Learn Impact: 

Connect with Kevin Dowdy: 

DISCLAIMER: This is not professional advice. The views are my own and the people quoted. Consult your own advisers for legal, business or tax decisions based upon information from this episode.

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

Subscribe if you’re ready to build the future. 


SPEAKER_00

In this series, we have high-level conversations about technology and the impact that it has on our community. I want you to be able to walk away with the tools that you need to grow your income, become an owner, and help shape what happens next in the world. This is your first time tuning in, you are in the right place. If you've been rocking with us for a minute, it's great to have you back. Welcome back. Let's jump into it. First up for the news for this week, US workers are more productive than ever. So there's a report from the New York Times basically saying that in productivity for labor has been increasing for the last six years. And I do want to just highlight what that productivity means, right? Just so we're on the same page. So productivity is defined as getting more out of a system over time than you did previously. So if the output was five of something and you had to put in an input of three, now increased productivity would be maybe we put in two and we still get five, or we put in three and we get ten or something after that. So that productivity is what we're measuring. For labor, that looks like a person putting in the same amount of hours or even less hours and getting more value from that employee. Either that employee selling more units of something, right? If you're in sales and you're getting more sales in the same eight-hour day, that could be a developer building a feature faster. And that could be something like a cybersecurity analyst catching incidents earlier without putting in more hours or having to do anything extra, more work, more input, or not having more people on the team for you to be able to catch the same amount or more of incidents early. That's how we're kind of measuring productivity from an output to input to output ratio. But an important thing to measure and to understand when we're talking about productivity, and what this uh report and article is also mentioning is the quality. We don't want to give up quality when we're talking about productivity, because just because you do more of something doesn't mean that the thing that you got out of it was actually better. So the productivity plus quality is super important to keep in mind. And a lot of the productivity gains that we're getting are built off of changes and decisions that were made six years ago, ten years ago, right? The cloud as a technology, as a platform that people build on, remote work as a way for companies to attract more talent or better talent to their companies without having to be in those markets, having offices in those markets, and all the other things that might be required previously if you wanted to build a team in a different area. These changes allow businesses, people in countries to just be more productive with their available resources because they don't have to, they don't have to use as much as they did previously to get the same results. And with that, one of the best parts about increased productivity is the fact that most times when a business or even a person becomes more productive, whenever they get more energy that they're saving, it's not like they do less, they often end up expanding their scope, they all often expand their market, they start doing more than what they were doing previously because now they can. Like, why not? And so we're we're seeing a lot of that today. But one of the most interesting parts about this article for me was that AI is not really a major lever in why we're seeing increased productivity today. And and it goes back to one of the quotes from I think some economists, basically, that productivity gains usually come years after the actual technology and tools that made them possible were released. Because right now, we're seeing a lot of investment into this these new platforms, and we're seeing a lot of investments and of energy, time, and resources into getting AI to be helpful, building out new tools, building out new systems with these additional tools. So we're not necessarily more productive right now, we're actually potentially even less efficient than we will be eventually because right now it's still a testing period, it's still deciding what works, what we don't need to do any more of, and what we can start doing a lot more of. That lever becomes more helpful for workers and companies in the next five years when we actually get a stronger handle on what these tools are capable of, and they actually start being implemented, not just implemented inside of the businesses themselves, not just being developed. Right now we're still in the build-out phase. Right now we're still building out the data centers to make the technology possible to improve inference, to improve training. We're still building out the teams to build the tools for the different industries that will need to be more efficient. So that's something that we should expect to see more of it later. But just like with any other technology over the last probably hundred years, but especially for the last 20 to 30 years, think about the cloud and what that unlocked for businesses and individuals after a few years of people just getting to know it, understanding what the value add was, understanding how to use it, a lot of that transformation becomes something that we can see it in practice and so much easier today, right? Like when the cloud was early and people didn't know what to do with it, or even let's say right after people and businesses started doing more of their migrations to the cloud. A lot all of those investments, those don't necessarily make you more productive at that point in time. But once you start seeing the benefits of those changes years later or months later, then you start saying, Oh, this is what this is why we had to do this, this is why it was so important for us to make that change. The same thing is going to happen with AI, the same thing that has always happened and will always happen. But one thing to keep in mind with this focus on productivity is that the goal is for productivity to continue to increase. That means teams will continue to look for people that are more efficient with resources. That means that people will continue to expect capital, labor, compute, all of these resources available to become more productive, never less productive. So in some in some companies, that'll mean leaner teams, right? You don't need as many people to get the same amount of work done. In the companies that can afford to keep the same size teams, they're going to expect more out of those teams. More output, better quality, more value, just because, again, that focus on productivity. That's what we're all going to, that's where we're getting. And with that productivity in mind, you have to remember that you have to continue to expect the competition to get better. Because if every if everyone is looking to become more productive and they actually do become more productive, you can't be the only one that doesn't experience those efficiency gains, that doesn't learn how to do more with less. So for all builders wondering, how do I become more productive? How do I make use of the opportunity that we have today to increase our productivity? The best way you can do it is to learn how to use the tools available to you. Think about all of the tools that are out here today and the ones that were possible now that weren't possible years ago, and what they can do for you and your ability to deliver great results. You gotta get super familiar with them. You have to understand where they're useful, where they're not useful, where the gaps are, and where they can really push you beyond what you currently know to be possible. Like having that understanding of the tools and well being able to execute very quickly against using these tools or against whatever your industry might be, whatever your function might be, being able to execute quickly with the tools available, that's going to become incredibly useful to you in order to be more productive. Because the more you execute on a function or a practice or an activity, the better and faster you get at it. So continue to practice, continue to learn the tools so that you don't have any friction when you're trying to do the thing that you're trying to do. But that's going to be one of the major, not just challenges, but one of the major benefits of the AI era is that we're going to be focusing more on productivity. So you have to be able to adapt, you have to be able to be agile and efficient as much as possible. In other news, big tech is being requested, expected to justify a lot of the AI spending because investors are starting to dump some of those stocks. From my perspective, I believe that there's a disconnect between what Wall Street is expecting, what investors, everyday Americans and citizens are expecting, and what engineers on the ground are expecting with AI. But like everyone is expecting, well, I'll say everyone, Wall Street is expecting the productivity and the profitability of these tools to increase dramatically. And we have seen the stocks related to AI perform very well in the last two to three years, even in the last couple of months. That's true. On the other hand, we've also seen the technology, the actual models themselves, not getting better as much as the stocks around them have been improving. So there's there's that disconnect. It's like we're expecting or the people investing in these technologies are expecting them to do so much more than what they're actually doing today. Not to say that they won't ever increase the efficiency of the teams using them eventually. They will. That's one of the things I was I was just mentioning. Like the productivity will be felt later on. But right now, we're still we're at that build-out phase. We're still trying to get the enough inference for all of the demand that is expected. Not even just expected, the demand that's available right now, let alone the future demand and growth, as people start to get more familiar with the tools and want more of it. But an interesting thing about just the expectation, and even this week, people claiming that the cause of the stocks related to AI falling was that the growth of these products is not as quickly or as fast as it was expected. I think we've gotten past the point where you're gonna start seeing significant changes in the capabilities of these models. Even Mythos and the latest Jeep Chat GPT models, even these models are being slowed down by regulation. So even if we could start to see significant increases in the actual performance of the models themselves, there are actual guardrails being designed and put into place to make sure that they don't actually come out as quickly as they could. Right? So there's some disconnected, there's gonna be a little bit of a barrier, there's gonna be some friction. So I think that's what we're seeing right now. Like short term, this is like a little blip when people are figuring out like how do we really value the technology as it is today, not what it can be later, right? Everyone is always expecting these companies to deliver better results, but what are they actually delivering right now? What is the value add that an enterprise gets from implementing or integrating AI into their systems, into their business, into their organization? That's going to be the actual, that's going to be where most of the growth is coming from over the long term. But over the I was like also over the long term, I'm sure all of these hyperscalers will rebound, right? Google is still going to be Google, Microsoft is still going to be Microsoft, they still provide technology that is necessary for almost every business, every industry, every sector. But we're not out of the we're not out of the place where they can actually start seeing those, I think I would say the best results. Even right now, we're starting to see some of the backlash against data centers becoming more set in policy, right? We're seeing more moratoriums in New York to stop data centers from being built out. We're seeing a lot of protests all across the country to stop expansions and new developments for data centers. We're starting to see different states making policy decisions to say that data centers need to take on more of the cost of their own energy. And that changes the productivity and the profitability of these projects wherever they are. So that's something else I'm keeping, I'm keeping in mind and keeping an eye on. Because I do wonder what happens when we start restricting the amount of supply available while not actually tampering any of the demand. Right? What happens when, like with housing, when you make it more difficult for builders and landlords to increase the amount of housing supply available, then the rents and the housing prices in that area become more expensive. It becomes more, like, because that's normal market dynamics, supply versus demand. What we're looking at today is there was a lot of demand growth, but also a lot of supply growth. We saw companies like X SpaceX, previously XAI, you know, building out data centers super quickly, with honestly breaking a few rules in the process, and then other companies doing very similar practices, basically just trying to build out the infrastructure as quickly as possible. Now that it's here, it's here. But if we don't allow anyone else to build after them, then all of those resources become even more important, and it becomes more useful and necessary for builders like yourself to understand how to be more efficient with the resources available to you. Because FinOps has been important inside of the cloud for years now, right? The cost of compute, data transfers, IPs, all of these things have continuously grown, especially as new products are being brought online and you know things are growing. But we're starting to see that as the increase in demand for AI grows and those tokens grow, while we're seeing uh more, I'd say the the supply of the tokens in the AI inference compute that has been being constrained a little bit, it becomes more even more important for builders to understand how to be more efficient with the resources that we have. You have to be able to go into a product discussion and understand what are the areas that are going to be the most expensive for us if we design our architecture in this way. And you have to be able to understand how to plan out a design, how to estimate the cost, how to switch and make a trade-off for availability versus maintainability and reliability and cost. Like all of these things become super important when we're talking about the efficiency of the infrastructure driving it and what that means for us building on top of it. And I saw a very interesting blog from Claude and Anthropic about the cost of code migrations shrinking. So along the same thing, productivity and what we can do today with AI that we could not do previously, one of the most challenging projects in any engineering organization or that any engineer will undertake is a migration. Now that could be a database migration, that could be a code-based migration, a migration from the on-prem to the cloud. Whenever you're trying to make a big change inside of how your system is running and how it's operating, that's going to require a lot of patience, a lot of care, and a lot of due diligence to make sure it goes smoothly, especially for organizations and teams that offer really critical services. So one of the projects that was recently migrated with the help of Claude Code was Bun. It's a popular JavaScript runtime that where their code was previously written in Zig, or I believe it was Zig, and they migrated it to Rust. When you're changing a code base from one language to another, first of all, they're like the coding of that is one part, the one challenge. That could be hundreds of thousands or even millions of lines of code that you have to ship to this new platform, to this new language. And that requires some time because you also have to make sure that all of the changes that you make are actually keeping the original implementation in mind, right? You you don't want to, during a migration, be adding new functionality, but you also don't want to lose any of that functionality that your customers and your users relied on. You have to be very careful when you're building out that uh change. But I think the most interesting part about what was mentioned in the blog was not so much that the code was much easier to write, it was all of the design decisions, the engineering thought and engineering leadership that had to go into making sure that this project actually went on successfully. Because the planning of a migration, the definition of the business case, and analyzing why this was actually valuable from a user perspective, evaluating the tests that defined and decided whether or not this worked or didn't work, all of that is still done by a human. All of that relies on a human engineer with actual experience in this area to make work. That's one of the things I wanted to highlight in this blog and this story, because the real work of engineering, software engineering, is still being entrusted to talented, hardworking, and creative people. You cannot give AI just a task like migrate my code base, migrate my database, and trust that it will do it properly. You still need people that are accountable, that actually know what they're doing and know what questions to ask AI, know how to direct these agents to actually give you the results that you want. And that's the value today that you can focus on. You can focus on differentiating yourself from AI by focusing on the conversations and the discussions around the activities that are important, but that AI cannot lead on their own. Like these agents can't understand why a decision you make in the engineering side, how that's going to affect someone in sales when they're trying to actually sell the product that you're building to a customer. You have to be able to make those connections. You have to be able to weigh the value of this engineering decision versus the business objectives that you are familiar with. That context and these context windows for AI have been growing. The reasoning engines behind them have been improving over time. But that human taste element is still something that we really can't give up. And sometimes it's just having the experience of knowing this is the process that we go through, and this is why this process works. If you understand that and recruit AI to work with you to go through that process faster, then you have a significant advantage versus someone else who's either choosing not to use AI, so they're going slower than they need to be. Or they're using AI and thinking that it's going to do everything that they need, which is going to increase the amount of mistakes that are made and overall lower the quality of whatever it is that they're building or trying. So your job as a builder in the AI era is to understand how do I lead this effort to not only solve the problem in front of me, but make sure I'm solving the problem in a way that the people around me, my team, the people, my stakeholders, my customers, that they can trust the outcome that I'm actually delivering to them. And that's not easy. That's not something that you can just give to AI. But the major thing that I'm seeing and hearing for this week is that everyone is seeking to be more productive. And this is really natural, even from the cells in your body. Everything is trying to become more efficient with the resources that it has access to. And so if you want to be your most productive, the best way to get there is focusing on developing skills that allow you to go through normal functions, normal activities faster without sacrificing that quality. And sometimes it's going to take time to get there, sometimes it's going to take an investment in the techniques and the knowledge that you need to actually know what steps to take. So it might feel slower at first. But once you have that lockdown, once you have it defined, and you can actually call upon it more easily, then that efficiency gain starts to really be felt. So just expect that little dip originally, like in the beginning. But over time, know that that productivity will increase if you continue to invest into your skills, your knowledge, and just how you do your work in the best way. But if you want to go deeper into any of these topics and explore the opportunities they create for you and your family, join BLI University. Every week we are discussing and building with some of the biggest tools and the best tools in the market right now. We're building with builders that are actually driving the evolution. Not just talking about it, not just reading about it. We're actually hands-on computers, writing code. We're actually talking and discussing the trade-offs we're making inside of the systems we are designing. And this is, you know, definitely something that you could benefit from. Or you may be able to benefit. Alright, we're gonna jump into the QA section for this week. First question: What is the engineering tip of the week? So the engineering tip of the week is to keep your branches current and push your work to any remote branches regularly. So any developer working on a project, you understand that, especially if you're working in a team, that a lot can happen inside of a day. Even more can happen inside of a week if there are multiple people playing around with the same code base. The easiest way to cause yourself stress is to keep your changes on your device without pulling any of the latest changes from the master or the origin branch that you're going to eventually have to merge back up with. The rest of your team is not waiting for you to pull or push your changes. They're going to make their changes as quickly as they can and expect you to make sure that your changes don't break anything that they've done. So you have to make sure you're merging as often as possible, at least daily, and make sure, not say you're merging or rebasing, uh, you've got to be careful about which one you're doing. If you're going to merge, that may be easier. If you're going to rebase, be careful with it because it does change the commit history. And so there are some scenarios like if you're in trunk-based development or in a trunk-based branching style, you may be able to rebase between let's say your production branch and your main branch or your production and development branch. But if you're having multiple people deploying to the same branch or some feature branch before you merge into development or main, then that might be a scenario where you want to focus more on just merging. Just to make sure you're getting all of the changes together and you handle any conflicts as they come. And even getting your code into your remote repository, another benefit of that is that you can start seeing your testing results and your security results much faster. One of the main benefits to a CI pipeline is that you can raise any security issues, any type of code quality issues, any broken tests much easier in the process versus waiting until you got to QA or production. Where the earlier you make that issue known, the cheaper it is to address it, the cheaper it is to fix it. The longer you take on your branch, if you've had it getting stale for about a week or even a month, and you've never actually decided to push that code up, then you don't know what decisions that you've made or what libraries that you've decided to use that might not be okay to use. They might have some security issue inside of them that you have to address, you have to resolve. So you want to get that tested as early as possible. You want to handle the problems before they become larger. Like, and this is a reason why you should push to your remote repositories. Like, one of the main reasons about having a version control system is that you can back up any of your branches, any of your code somewhere that is more durable. Nothing is worse than working on a feature for a day or a few days and then having all of your changes lost because something happened on your device. Either you ran out of space or storage and your computer crashed, or you could lose your computer. Or if anything could happen to your device, if your device was the only place where this code was stored, then that means you're going to have to not only replace the device, but you're going to have to recreate all of that code that you just spent days or weeks working on. So you want to avoid that as much as possible by making sure your code is pushed where it needs to go so that you always have a reference to it. You have always have a way to get back to that state. But definitely focus on getting your code into your repository so that either you can have it for the future or that members of your team can at least see what you've been working on. When should you consult with IT or cybersecurity professionals in your development process? So the question that you need to ask whenever you're deciding whether or not you should or you need to consult with cyber or IT versus when you're okay to just build on without discussing anything with them is does my change actually change the organization's risk profile? Am I doing something that's going to make this environment or this system less secure or more secure? More secure is not really an issue. Usually you want to focus on if you're making something less secure or if you're not sure whether or not or what impact your change is going to have on that environment. Like if the answer is it does not affect the risk profile, you're not making anything less secure, you're not opening up opening up any trust boundaries, then you know go for it. You don't have to speak to IT or cyber right now, you're good to go. If you are not sure what impact the change is going to have on the security or the privacy of the system that you're working on, you have to discuss it with them to make sure you're not introducing any type of unnecessary risk. So I ran into this challenge this week. Well, not even the challenge really, but scenario. Because most of my team has developed their automations, and a lot of the systems that we rely on in my team have been built using UiPath or Excel. That's how we are, you know, doing our automations to pull data and even to build our reporting. I have transitioned to using Python for browser automation and even data processing, like using pandas and playwright packages to do that. So this was like a shift in the technologies that we use to do the same work. And this week, I end up taking a day off and I had to kind of transition one of my team members to take over my role, at least for a day. And during that KT, it was asked to me, you know, have I been, have I discussed with IT to use these tools? In my case, I didn't have to. The Python runtime that I installed, that wasn't from the internet. That was from the authorized software center that the IT team told me to pull packages from previously. This was like weeks ago for some other scenario or some other issue I was running into. The browser that I'm using to automate the functionality, that browser also came from the software center. So there's no risk that the supply chain that I'm pulling from could have been compromised. And not to say that it won't ever be compromised. There may be a time where I may have to patch the version of Google Chrome or Python that I'm running, but that's something that IT is already managing. They already know what version that they've deployed to all of our devices. They already know what to keep an eye on if there are any vulnerabilities that are found. And I'll just get that request at the time. But right now, there's nothing really to be done from that perspective. And then from an actual process perspective, the system that I'm that I automated or the process that I automated is not a new thing. I've already been doing the work, doing these activities. I just built a script to automate it. So it's still using my same credentials, it's still going to the same locations, it's still pulling the data and pushing it to the same areas that it used to. There's no been there's been no change there. And I continue to run that automation on my device. So it's not like I introduced any type of new environments to access some type of data source that it wasn't previously able to access. So in my scenario, in my case, there wasn't any major need to consult with IT to get this system approved or anything like that. But if you're working on some net new system where you haven't actually where you haven't actually consulted with cyber, you may need to consider doing that if you find yourself opening an environment to some other environment. Like let's say you're connecting a database to a new cloud environment. You have to consult with cyber at that point because you have to understand what can access that cloud environment can now access the database. And that changes the risk and the threats available or possible to that data source. If you're installing any type of new packages or systems, if you're if you're getting them from your company's approved repository, whether that's like Artifactory or Nexus, that's fine. Those have all been reviewed to make sure that they are secure. You don't want to just be installing random tools or technologies from a repository that's untrusted because now you're bringing in a riskier technology or riskier tool into an environment that has been designed to be more secure. It was designed to not run that type of risky software, but now you're bringing it into the trust boundary, and that can introduce another surface area of attack, even with me installing the packages that I use, they're coming from approved repositories versus me just pulling some type of package from GitHub and just cloning a repo and using the code that was available there. And then like my supply chain, I've made sure that that was secure, as well as the policies, nothing else changed there. So whenever you're thinking about whether or not you need to bring in cyber or IT, understand what exactly you're changing and what impact that change is going to have for the security of the environment or the industry that you're working in. That type of judgment and decision making is the difference between someone who's just writing software and someone who can actually build inside of an enterprise environment. Can't just build like it's just you. You have to recognize that the goal is to keep the business going, not just to keep your code running. Are there certifications worth getting? The short answer is yes, but probably not for the reason that most people think. The value of the certification is not in the piece of paper itself or the digital check mark itself. The value to me, in my experience, has been the knowledge that you gain from studying the concepts that that certification might be testing or assessing, and the say the brand value of the authority that's going to sign that credential. So I recently got my CISSP. So I've recently passed the CISSP exam. And that credential was something that it had shown up on a number of job listings that I had been interested in. So it was something that the people that I want to work with in the roles that I want to work in, they're looking for this certification as a preferred qualification. And they're looking for this specific certification because the certifying authority, that certifying board, is noteworthy. They're trustworthy. This is an actual body that spends up significant amounts of resources in creating the tests to make sure that they actually validate the people who have the knowledge or not. And so the fact that that qualification was asked for like not only by the jobless things that I was going for, but even my job itself. They wanted me to get a certification. I chose to get this one that I was looking for because it aligned with the roles that I want to get in the future. And I know of some people in my current team that actually had it, and we were able to discuss the value that they found from that credential. That's what made it something worth pursuing for me. But the credentials are not proof that you actually know what you're doing with the technology or with that domain. The credential only signals that you have some familiarity versus no credential. We don't know if you know anything about what you're talking about. You might just be good at faking it. And that's what a lot of companies are kind of worried about right now. With AI and with just where we are today as an industry, there are a lot of people that don't actually have the skills to operate like an engineer, to operate like a security professional. These credentials, whether it's a degree, whether it's a certification, they make it more likely for those teams that you're looking to join to trust that you at least know something, something about what you're going to be expected to do. So they don't have to spend or they might not have to spend so much time training you or getting you uh onboarded. You can actually be able to deliver value earlier versus them having to teach you everything about what you need to do in this role. So I would say when you're going for any certification, focus on understanding the topics that are inside or being tested by that certain. Because for me, there's understanding the definitions of the words that are inside of the domains for the CISSP was valuable. It made me understand the different components that were that I've used before, but that I never really had a name for. That became super valuable to me and something like a reason why I think the certifications were worth it. But you should definitely view the certification and study path as a structured learning opportunity versus proof that you actually know how to get the work done or do the thing. You should have other projects and experiences where you actually learn to do the thing. And the cert is just a nice icing, like uh icing on the cake. What are three ways to reduce your cloud bills? So, one very critical thing to do is to shut down unused resources. In the cloud, there is no distinction between something that you're using and something that you're not using. If you have provisioned an EC2 instance, if you provision some type of storage, an IP, they are going to charge you for that resource, whether you are using it right now in your production or like inside of your operations or not. So you have to be very careful about what you deploy into your environment and have rules for how long they can stay. So that could mean inside of your development environment, not letting certain resources be long-lived. Do you need an EC2 instance available 24-7? Or do you only need it available during business hours? Do you need a high, can you use serverless compute versus a you know always on instance? These types of decisions allow you to dynamically turn things off and on as they're needed, when they're needed, because you want to reduce the amount of cost that you're going to be paying. Another tip there is to set up an approved process for deploying resources, right? Like you shouldn't have every developer in your organization able to go into the console and spin up an S3 bucket or configure a CloudWatch logs or any type of EC2 instances. Like they're using the biggest EC2 instance that they could find versus using a small one. You want to have a defined process in place for getting these resources provisioned for them. And you want to have a way to manage that that configuration, right? You want to make sure that everything is the right size for the use case and the environment that's going to be running in. So that might mean in your development environment, not having backups set up for logs, for logs or data storage inside of that development environment, versus in production, you might be doing a snap or taking a snapshot every hour and keeping those backups for maybe a month or even six months, whatever it may be, to fit your policies. That might mean in production, having larger resources provisioned versus in development, there's a certain limit to the amount of compute that you need because this is not a production environment. A lot of that should be defined preferably by infrastructure as code. Like I've been working with Terraform recently to make sure that I can deploy anything into my environment, but that I know from a text base what exactly I'm deploying. And I can look at that and either destroy everything, like shut it all down at once, or redeploy it when it's needed. That becomes very helpful from an audit perspective to see what type of configuration you're using and to make sure it's always uniform and standardized. But it also makes it easier for you to know how your infrastructure has changed over time. What new Resources have you added in the last month that could affect your cost, whether that's increasing the storage size, the retention policy, anything like that, that can all be defined with infrastructure as code. And then a little known, I guess, option for controlling your cost inside of the cloud cloud is to use that provider's price calculator. Now the price calculator is not going to be a like it's not going to prevent you from exceeding your cost, but it's going to make it much easier for you to know what you're going to spend with a specific architecture. And then if you do the price calculations and the estimates before you actually build out the system, when you just have an architecture design, you can actually go through the process of maybe making some trade-offs to either update the architecture to fit your budget a little bit more nicely. That could mean you know right sizing the resource because you don't need the level of availability it was providing. That could mean you decide not to transfer some type of data in or at a frequency, right? Because data transfer costs could impact your overall balance or your overall uh cost inside of the cloud. So you might decide that instead of a you know a let's say a min every minute doing a data syncing, maybe you do that every hour or every day based on your business needs because it's still fine with you. If you don't estimate those costs earlier on in the process, then you start and potentially make decisions that are going to be more expensive for you over the long term. So take some time to go through that and make the trade-offs before you invest the time into that system. Because the longer you go with an architecture or design that doesn't actually fit your budget, doesn't fit your financial goals and your business goals, the longer you're going to be paying for something that's more expensive than you need. And that's one of the most valuable skills that an engineer can have in this era, especially as you're developing or uh products with AI in the cloud. Like FinOps becomes a more important skill set, a more important concept to understand when we're trying to be more efficient with all of these resources that are necessary to build a modern application or a modern system. And when should you take a break? So a lot of people think that breaks are something you have to earn, that you have to work hard, and then at, you know, once you've worked hard enough, then you can take the break. But I personally think that they're really a tool for managing your best performance and getting the best out of yourself. So I think it's very important to take a break, especially when you're seeing the quality of your work decreasing, right? When you're missing deadlines or getting close to missing deadlines and things are slipping, then you have to make sure you take some time to reset to make sure that the standards that you have for yourself and the standards that are expected of you are being met. Like you don't want to not take a break and then start pumping out poor quality work. Then if you're going to make a big move or you're making some type of big decision, I would also recommend you take a break, right? Because once you start getting in the thick of the change or the thick of a project, it's going to be very difficult for you to take a break at that point, right? You're already in the middle of it, things will be changing really quickly. If you like, I know this is something that we talked about in school, but like if you miss a day of lesson instruction, then a lot of times we're behind. Like it's really difficult to catch up once you miss a day of something. So it's very important to take the break before that type of project is started. Because often, if you wait until we're in the middle of it, you can't turn you can't call timeout. Well, at least you can call a timeout, but it's not going to affect the rest of your team because they're going to still be building and iterating at the speed that they were previously working on. So get that rest beforehand. And then I also think it's important to schedule your breaks and schedule them periodically. So, like every month, I make sure I schedule at least one day to rest. And that rest doesn't always have to be me sleeping or staying in. Sometimes that rest is me just taking my mind off of the project, taking my mind off of this technical thing that I'm focusing all my time on. Or sometimes it could be doing something I hadn't done in a while, right? You know, going to see family, going to go to a movie, or just taking a break. Like having that scheduled in monthly has been helpful for me to make sure that I at least have some type of additional rest to look forward to. Then I also take at least a few days, ideally a week every quarter, to get a deeper rest, to get consecutive days to just allow my mind to not focus on the problems, to just think and explore and be creative. And during those times, it's really just about focusing on reflection, like either reflecting on what I've done or reflecting on what I expect to happen over the next quarter. That time is super important for me because it helps prepare me and sharpens me for the next steps and just makes me feel better and do better when I come back into my team or my project or whatever I'm working on. But one thing you'll learn as a builder inside of the tech industry is that it's always better to have a planned break versus a forced recovery. Right? If you're not taking breaks and that causes you to burn out, then that recovery from the burnout is always going to require more energy and more time than if you had actually planned that break and made sure that you were well rested when you entered any of the challenges that you were going for. So if you're starting to see your health slipping, high levels of stress, or potential burnout, you have to make sure you are taking a break. And then in the future after that, make sure you take the break before you start seeing those signs. Because once you see the sign, it's almost always too late. And the goal isn't to work less, the goal is to make sure that the work that you put in is always the best work and always the most valuable because we're focusing on longevity, not quick burst. We gotta be here for the long term. And one mindset tip before we get out of here is that you should find people that you can learn from and stay very close to them. And that could be a mentor, that could be a peer, that could be even a junior that you're mentoring and providing uh support to that can offer a perspective that you wouldn't have without them. Like the relationships are going to be very powerful, they can be negative or positive, but when you find a positive relationship that can actually improve your skills or improve the way you think about a problem, think about challenges in your life, you want to make sure you lean into those relationships as much as possible and stick with those people because you want to take advantage of that growth and that opportunity that they are providing. Like they're going to help shape the way you believe in yourself, they're going to shape what you think is possible and how you interpret challenges. And that's something you can't give to yourself, or at least I'll say it's more difficult to give to yourself. It requires way more reflection than most of us often have time to get. So getting it from the person beside you that's with you, that's on the same type of time and that you're on, is going to always be the better alternative. And that requires you to remain teachable. That requires you to focus on listening and not always just shouting what you believe and what you think, and be able to contribute also to that relationship, right? Not just always taking from the person that's you or from the mentor, like being able to give to them also, give the opportunity, give some advice, give a tip that they can also benefit. But having that relationship, having that person that you can learn from is something that you really need. It's really something worth investing into. And that's all we had for this week. Uh I already mentioned it, but well, let's announcements, shout-outs, sharing, and things like that. I did earn my CISSP, and I put out a video talking about my experience, how I prepped, you know, what I learned during the process. So check that out. I'm gonna put the link inside of the comments. So check that out, might learn something. And then also happy birthday to my little brother Kim. Uh Candoman, you are growing into a very intelligent uh young man. And I'm very proud of you. I'm proud of the way you are thinking, and I hope you continue to think for yourself and continue to be yourself and continue to you know be a man that a young man that you can be proud of and that I will continue to be proud of. So continue being yourself. I love you much, and you know, we're gonna have some fun whenever you get back from your birthday trip. So enjoy. Happy birthday. And also, I'm gonna be taking a month off of Software Sundays. Speaking of breaks, right? I will be returning on August 23rd. Now we're gonna be back with better energy, better information, and better resources to make sure that everything that we are delivering is super valuable to you in your development as a builder, as a technologist, and that you know we're helping you become what you're trying to be. And so I'm gonna take some time for myself to make sure that I'm sharpening my sword so that I can come back and be that resource for you. So I will see you all back in the next month. Happy Sunday. Enjoy your summer and enjoy your time in the sun. Get some fresh air, touch grass, and do your thing. I will see you very soon. Peace out.