Microsoft & OpenAI Power Struggle, Data Centers Reshaping Energy Demand and AI's Impact on the Workforce | Software Sundays

This week on Software Sundays, KD breaks down the growing power dynamics shaping the future of artificial intelligence, infrastructure, and the technology workforce. 

We start with Microsoft CEO Satya Nadella’s testimony about Microsoft’s relationship with OpenAI and what it reveals about cloud infrastructure, AI dependence, governance, and the massive ecosystem required to train frontier AI models.

Then we get into the explosion of data center energy demand and why the AI boom is accelerating investment into cleaner energy systems like geothermal power. KD explains the tradeoffs between economic growth, energy consumption, environmental concerns, and why developers will continue to play a central role in the future of digital infrastructure.

 We also unpack why companies are shifting hiring strategies toward experienced engineers instead of relying heavily on junior talent paired with AI tools. KD explains why repetition, real-world problem solving, and operational experience still matter in an era dominated by automation and AI acceleration.

 In this episode’s Q&A, we cover:

•  The difference between human error and incompetence 
•  How to explain technical jobs to non-technical people 
•  When businesses should automate processes 
•  The difference between building systems and operating them 
•  How deeply engineers should learn specific technologies 

We close with a mindset conversation about priorities, discipline, and why people with the same amount of time can still produce radically different outcomes.

CHAPTERS: 

02:00 - Microsoft, OpenAI, and AI power dynamics

08:00 - Data centers, energy demand, and geothermal power

14:00 - Why companies are prioritizing experienced workers

19:00 - Human error vs incompetence

26:00 - Explaining technical jobs to non-technical people 

31:00 - When should you automate a process?

37:00 - Building systems vs operating systems 

44:00 - How deeply should engineers learn technologies?

50:00 - Priorities, discipline, and performance

#SoftwareSundays #OpenAI #Microsoft #AI #DataCenters #CleanEnergy #SoftwareEngineering #CyberSecurity #CloudComputing #Geothermal #Technology #Leadership #BuildLearnImpact #TechCareers #Engineering

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

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

Transcript

SPEAKER_00 0:00

Welcome to Software Sundays Builders. I'm your host, KD, and I create systems that use technology to solve problems. And this is a space where we have high-level conversations about technology and the impact that it has on our community. And we want to make sure that you have the tools and resources that you need in order to grow your income and help shape the next wave of innovation. So if this is your first time tuning in, you are in the right place. Thank you for being here. And if you've been rocking with us for a minute, it is great to have you back. Keep coming. Quick disclaimer before we get started: Software Sundays is for informational purposes only and is not professional advice. The views expressed are my own or those of individuals quoted. And the topics discussed may or may not have or apply to your specific business situation. So please consult your own professional, business, tax, or legal advisors before making any decisions based upon information found in this show. With that being said, the information is accurate, it is great, and it is right on time. So let's jump into the news for this week. First, Microsoft's CEO had to take the stand this week and elaborate over how much power they actually have over Open AI. So a few months ago, uh Mr. Nadella once said that we are below them, above them, and around them when speaking to a journalist about his relationship or Microsoft's relationship with Open AI. And the lawyers in the Open AI versus Elon Musk trial this week wanted to know exactly what that meant. The problem is likely that as a nonprofit, the governance and strategic direction of the organization all has to come from the board, and the board has to follow and abide by certain rules when they're making any decisions based upon how they're going to direct the organization and the resources that the organization uses. So when you're talking about a for-profit company that is having or saying that they have that much of a grasp or grip on this non-profit, that's going to raise flags to regulators about really who was in control and who's supposed to be in control with this relationship. So when he was brought on trial or brought to the stand, uh Mr. Nadella basically testified that his description was more of a technical one, and it was not about the strategic direction of the company, it was more likely based upon the fact that Azure Cloud supported OpenAI's development of their Chat GPT models and products, and that OpenAI's products has been able to support and enhance the products and tools that Microsoft delivers to their customers. Developers, we need to understand, and it's important to understand, that the training of the OpenAI models required an immense amount of compute. A lot of that commute compute, especially early on, was provided by Microsoft through their Azure Cloud services. So we're talking uh compute instances, we're talking uh Azure functions to handle any you know uh serverless actions and maybe even having their storage buckets from Azure to store training materials or training data as well as some of the code that ChatGPT actually uses to run. A lot of that was all necessary to enhance and develop OpenAI's models and their products. And then on the flip side, when we look at Microsoft 365 and the how deeply nested Copilot has become into all of their products, a lot of that innovation was driven primarily by integrating OpenAI's models into their products, and that's how they enhance them. So that relationship has been very helpful for both parties. It's it's been bio symbiotic, where they both benefited from the other company or other organization continuing to grow, continuing to build and enhance their products so that the service that they provided to each other just became better and became easier. Of course, Microsoft has other clients than OpenAI that they were providing services to, right? They are one of the most trusted brands in terms of enterprise technology. So most enterprise level companies have already been trusting Microsoft with their infrastructure for years, and so OpenAI is very is a small fork uh small piece of that that is still relatively new. And on the other hand, open AI, they s they really do need their cloud partners, they have expanded to beyond just relying on Microsoft's compute, right? They have deals or they had uh some deals with Oracle. Um, they've looked, they've worked with Amazon and other partners to provide the necessary compute that they need to actually uh grow and continue to innovate on their models and compete inside of that AI model development space. But it's always been a relationship that for a time required both of them to be on board with. So just something to keep in mind as developers to understand the ecosystem that we're building in and the partnerships that go into making sure that all of the things that we kind of rely on to just work actually need to work. Next up, I want to mention that data centers are or data center-driven energy demand is actually accelerating clean energy adoption inside of the US. I I've been seeing a few stories and posts about Kevin O'Leary and his run to defend his plans in Utah to develop a new data center project. And there are claims that once this project is completed, it's going to generate and consume more than twice the amount of energy that is currently used across the state of Utah.

SPEAKER_01 7:14

So just to quickly unpack that first bit.

SPEAKER_00 8:02

And yes, they do. They have to always be on, they have to have backup and redundant power, they have to provide heating or cooling for a lot of the date the server racks that are being kept. And that's not cheap, that requires a significant amount of energy, uh, 24-7. Right? So that's totally true. I am curious what is meant by it's going to generate that energy. Because I know there are and there have been uh claims or at least kind of attempts to make sure that data centers that are being built are being built with enough capacity in mind to actually build their own energy and what instead of becoming an additional uh just user or consumer on the existing grid. And because there's not enough energy, there's not enough energy to go around currently and to meet the current demand. So when you're we're talking about doubling or tripling the demand on the same grid without increasing the same the amount of energy available in that grid, we're gonna run into some issues there, and it's gonna lead to higher prices, higher energy costs, and a lot of bad things that people kind of don't want to deal with and are already struggling to deal with. So I think that's part of it. But I still think that data centers are necessary for economic and social growth, and they are a very good thing personally because, or I'll say personally and for all of us builders, because data centers are all going to require someone with software engineering skills to operate the applications that run on those sites. When we're talking about AI being used to build more apps, AI being used to enhance some of the existing products that exist. You need a developer to actually go in, architect, and design these systems and operate them across their entire lifecycle. Those developers are you and I who understand technology, understand the trade-offs, understand the challenges that come from building and scaling software. So that's a great thing for us. The problem, again, is that people mostly focus on is the energy cost issue. But I think a more significant problem with the fact that data centers are consuming energy and that just normal states and people are consuming energy is the plat the fact that nearly 60% of the energy that is generated inside of the US is coming from fossil fuels. So we're talking about natural gas, which is clean nerve, then coal, but still not great for the environment because it does release emissions, and then coal, which is about 20% of the total energy generated in the US. So that's which is horrible for the environment in terms of the amount of carbon that it's actually creating creating. So the energy grid or the demand on the energy grid is the problem because we're as we continue to use more energy, and as more things need to use more energy, from beyond just data centers to e-bikes, electric vehicles, uh just normal day-to-day heating and cooling of homes as we're talking about climate change. Uh, all of that is also having a large impact on the climate. And I think the great part about the fact that we're seeing increased demand is that it's making it one shine well shining more light on the fact that energy sources matter and that we need to be more mindful about where we're getting our energy from, and two, it's making the investments into cleaner energy projects more attractive to investors. So another project that is also happening in Utah is that Fervo Energy is using oil and drilling, oil and gas drilling techniques to unlock vast amounts of energy from the Earth's interior, and they're going at it not from oil or gas, they're going and drilling to find geothermal pockets so that they can start creating geothermal energy uh generation sites. So, geothermal energy is a renewable energy source, it is clean and it's 24-7 available around the clock because the Earth's core is always providing that heat, and it's something that we can rely on more reliably than solar or wind power, and again, much cleaner than coal, natural gas, or any of these other fossil fuels. And so the company Fervo Energy is benefiting from the increased demand inside of energy because now they can make an argument to investors and to the government to say, hey, the problem that we're solving, finding more reliable energy sources is actually worth it now because we're starting, we're we're starting to see an increased demand in the energy and for the energy that is available. So it's something that it's worth putting some money into this. So that's one of the major things and keys to remember about data centers and what it actually means for our community, our society, and our nation moving forward. Another interesting story for this week is that the workforce statistics are shifting in favor of workers with more experience this year. Reports say that more than 40% of CEOs plan to cut junior roles over the next one to two years and shift the composition of most of their workforce toward mid-level or senior positions. And this is a dramatic shift from where we were a year or two ago when companies thought they could cut cost by chopping most of their senior staff and just giving the junior staff AI and letting them go to work. The problem in that equation that wasn't totally clear originally, but is super clear now as we start to see the limits of AI, is that it doesn't scale well. When you're giving a tool that helps people move faster, but that doesn't actually have real-world experience to someone who also doesn't have experience and is unclear about the processes and frameworks that exist inside of a real organization and in the real world, you start seeing gaps, you start seeing breaks, and you start seeing steps that should not have been skipped being skipped. And so when we start seeing reliability issues across a number of industries due to them getting rid of rid of a lot of their you know knowledge, and that knowledge being the people that knew the information that were familiar with the systems, like when you get rid of that and then replace it with juniors who don't understand and don't have all of the information that they need, then we start seeing these reliability issues. So it's very helpful for the seniors at this point to you know start seeing that shift. The challenges for junior engineers, junior professionals how do you compete when the employers, the people that are looking for services and labor, when they're looking for people with experience. And if you're a junior, you're trying to get the experience. And so if you don't get the role because you don't have experience, then how do you get the experience? So that creates that challenging cycle that could come back to bite us in the behind in a few years if we don't actually invest inside of our junior engineers and our junior developers to make sure that they can train and grow into the roles that we need for them in the future. So that could become a challenge, but something to think about as you are applying to roles and going into um you know, taking on some of the roles that you get just get access to, is that experience is going to create and build the critical thinking skills that make you as a professional more valuable. When you go into a project and you actually have to solve a problem, when you run into a challenge and have to look for and research a solution, when you have to document, you know what the problem was, what the solution was, and what your options are. When you go through those exercises, then you actually become someone who can do it again in the future, and that's the thing, that's the key that's missing for most junior engineers that never actually tried to do the thing. A lot of people spend a lot of time going through tutorials and focusing on getting credentials without understanding that we want to understand exactly what you do, what problem you can solve because that's what is getting invested in, that's what's getting funded at the current time. So it's also helpful to remember that experience doesn't necessarily mean you have more years in your career, it just means that you've also tried more things than someone else. So it's helpful to think of your experience as the reps, it's the amount of things that you've tried, it's the number of systems that you've broken or have experienced being broken, it's the problems you fix, it's the solutions you have shipped have shipped, and it's the customers you've dealt with while handling ambiguity and all of the failures you've actually learned from. When you're putting in reps and actually trying to do the thing, when you go through every day for a month to actually solve the problem and you get a little farther each time, when you go through and do the actual task and go through all of the steps and realize where you can improve on this step or what can be removed because you can optimize to get to this next step and either save more time or save more energy. That's the type of experience that we're looking for that is being valued currently, and you can get that without having to go spend a bunch of years on the job. The the challenge and the problem is that someone that has been complacent in their role for 10 years could have less meaningful experience than someone who just hustled for the last six months to learn and build their skills and actually create a project and go through the actual reps again. It's that repetition. When you're going through repetition, it makes you stronger and it makes you grow faster than someone who's just being a little timid about how they want to do the work and not really mindful about what needs to happen on the other side. So something to keep in mind when you're thinking about growing your career and starting your career and figuring out how to get the next opportunity ahead of you. So that's the end of our news section for this week. If you have any questions or if there's anything that I missed or you would like me to shed a little bit more light on, definitely put a comment inside of the chat. Put it on um, yeah, let me know what you what your thoughts are, what questions you have, and we can add some more clarity and depth to any of these sections as needed. And also like, comment, and subscribe. You know, let YouTube and us know that you actually are enjoying the content on the channel, uh, and we can continue to do more or we can improve and know exactly what to add in the future. So thank you for that. We're gonna jump into our QA section now. And these questions and answers are designed to provide a little bit of light and clarity into the role that you'll have as an engineer and as a builder when you step into your first project or when you're looking to transition to your next one. So definitely keep tuned in or stay tuned in and you'll learn something very helpful. So, first question we have for this week is what is the difference between human error and incompetence? And this is totally helpful for the juniors because uh we're gonna go through challenges when uh people on the job are judging you every day based on your ability to meet their expectations. And something to keep in mind for builders is that the expectation is that you understand the meaning and the value of the work that you are doing and understand exactly what steps and prerequisites are required to get the work done. Human error is Mistake that is made when someone is tired or overworked and can lead to them and can lead to issues that are difficult to actually catch because you usually expect that person to be doing it right every time. This usually comes, especially in security operations, when people professionals are getting bombarded with too many escalations or too many requests or too many things at once and have to manually review each task or each ticket in order to make a determination for next step to know how to escalate, to know how to uh make a decision from it or figure out what next to do. A lot of that human error is more of a load issue on one person or one team or one department, not having enough resources in place to effectively manage the work that they're getting. Incompetence is a mistake that is made from someone who doesn't currently have the skills required to solve the problems in front of them. And I want to highlight it's currently your incompetence for someone that wants to learn is going to be overcome over time because they're going to invest the time and energy into getting and developing the skills that they need to meet the expectations. But incompetence is going to be more expensive to fix and it's going to take longer because you know you don't need to just you know shift around a few team members to or give someone a break. You have to properly train that person, and that training is going to require their engagement over an extended period of time and an investment from the organizational management to give them the time required to actually develop the skills that they need. But again, human error is a little sneakier because teams can come to rely on someone who is actually competent, but when they put more pressure on that person or that team or that individual, that can lead to the issue of them be you know having a human error in the first place. So some of the solutions or checks that you need to have in place to protect against both problems is to make sure that you are doing proper screening. So you gotta have a hiring process that actually is searching for the people that have the skills that you need and not just theoretical skills and or understanding of the concepts. They need to have actually practice with the tools or similar tools or practice within similar companies on similar projects and problems. So you have to understand you have to know that they can learn fast enough because they have been learning fast enough, or you have to know that they can do the work because they have been doing similar work, and then you have to have processes or systems in place that can validate important outputs for accuracy, so making sure that some data set that is being generated by a person or human or even an automated system makes sure that you have a way to check that everything that's supposed to be in there is in there. It could be a simple check for just the size of a file, it could be a simple check to make sure that a format is in place, it can be whatever check is necessary and based on your actual business processes. You want to make sure you have that defined and documented and have some way to put that in place for when you know whenever the operation occurs. And then you want to make sure you have some processes in place to ensure your team is managing load well. You want to make sure you're taking care of the people on your team, giving them enough breaks, giving them enough rest, and giving them enough support so that they are always ready and refreshed to do the work with a clear mind and enough energy. How can I explain my job to a non-technical person? So the funniest part about this is I have a cousin that if you ask her what I do for work, she's gonna tell you that Kevin makes integrations. And that's mostly true for some parts of my day. But it doesn't explain what I do every day, day to day for some, and it's almost impossible to explain to someone who doesn't either do the work with you or who wasn't in the industry exactly what you do with and to a clear degree. But you can kind of have a framework that allows you to at least explain it to the people who need to understand and need to know. So I start with the high-level kind of this is what the value of the work is at a high level. Then you can highlight some of the tools that you use or the problems that you're solving, just to give a little bit of clarity. Uh, people that don't know the tool is not they're not going to really catch everything that you say, so it's not about focusing on the tools, it's focusing on saying that these tools allow me to do this in my my role, and then you can kind of put that together and say, This is what happens when my role is not there, this is the problem that I solve. It's a little different from the high-level what is the goal. This is like the inverse. What happens if I don't do my job? What happens if we don't have this person doing the task? Or what actually happens when we have this person doing the task? So that's something to keep in mind. So high-level weeds and then benefits to explaining your role. So if I were to talk about my current role, my job is to help executives make data-driven decisions about application security. And I use tools like Saltminer and Fortify to aggregate application security data and use that in combination with Power Automate and Power Uh BI, amongst other tools, whatever works at the time, to help create reports that allow stakeholders to make sense of the data that we have available. And because of the accurate reporting that I provide, application owners are able to effectively make decisions on resource planning, change management, and risk management strategies related to our portfolio of over 800 applications that support financial institutions, banks, and other merchants inside of the financial institution or financial services industry. So that is like the description that I could give to a recruiter or someone that is familiar with the technology industry. If I were to describe that to someone who was just getting into tech, then I might say something like I use or I would change the actual description that I'm giving to make it make sense to them. Like I integrate data from multiple sources to create data pipe, or I create a data pipeline that integrate data from multiple sources and use that data to create reports that it that improve decision making for executive leadership. I think that's clear enough to someone that doesn't know anything to, and in general enough, to someone that doesn't know anything about the industry to say, alright, kind of this is what I could even uh potentially ask this person about. Because that's really all you're trying to do when you're describing what your role is. You're trying to make it make sense to the to your audience enough that they know what questions to ask you, they know when to call you whenever there's a problem, or they know what not to call you on. Like some things you shouldn't call me if your computer screen is broken. I don't fix computers, although I have in the past. But my main thing is the software that runs on that computer. So now I could help you with these tools, or I could help you with these operations in your business. That's the type of clarity you want to give when you're answering that question. What do you do, or where do you work, or what do you what services do you provide? Next question is when should you automate a process? And whether you are building a data pipeline or a workflow orchestration system, you should deeply understand the process end-to-end before you write any code to automate it. I see too many builders jumping straight into writing code or configuring a tool before they have an ultra-clear picture on what the requirements are and what they actually need to produce. As an engineer and as builders, we are tasked with delegating ownership of our business process to a machine. And we always have to remember that machines are not as smart as we are, they are only going to do exactly what we programmed them to do. Even the smartest AI model is only going to be able to operate within a very limited scope because they don't have the creativity and the context that humans are able to call upon. So that machine could be an Excel macro, power automate flow, or some custom Python API. The only thing that matters is that it can do the job that we want to give it reliably. So we have to make sure we give it a very clear job description and we give it very clear rules on how it needs to do the job. And that's not something that you can do unless you, as the developer, as the builder, as the engineer, as the architect, as the designer, unless you understand that process as much as possible. Because imagine trying to teach someone something you don't even understand, and that's what happens when you try to automate a process that you're unclear about. If you try to automate any process before you are clear on the outcome or the deliverables, then you're gonna make more work for yourself because now you're gonna be able to automate everything up to the review process. So instead of it being done one per sec once per second, you're gonna have 10 new tasks being created per second that you, as the person who is responsible, the person who is accountable for the outputs, you need to review that work and you need to validate that work, and then you become the bottleneck for something that was automated earlier in the process, up or upstream, but now downstream, we can't automate the process. Or if we do automate it where we just trust the output of the system without testing it and validating it, then we could potentially start releasing less than accurate results to our customers or our end users. And we again we're responsible for that outcome and the impact that it has on those people in their lives. So you are you might as well provide that check yourself, and again, it doesn't help because you're still becoming the bottleneck, and then if you automate a process before you are clear on the process that is required, or the steps that are required, or the procedures that are required to do the work, then all you do is scale your ability to produce incorrect results because at this point you don't even know if the thing that you're trying to do is right, so you could be doing the wrong thing and doing it faster and doing more of it the wrong thing for more people, and so this is going to allow you to produce more results more quickly or produce more wrong results more quickly, which again is going to cost you money, cost you time, and this is not the goal that we have when we're trying to automate systems. We want to make sure that whatever we do, whatever we're trying to automate, we do it in such a way that it makes sense for the actual business and the outcome that the business is trying to produce and meet. And then something else to consider when we're thinking about automating a business process is that the cost of automating that process should not be more than the value of automating or having that process automated. If you're about to spend three months to automate a process that only takes five minutes per day and you're only doing for one person or one user or one company, one client, that's not going to be as beneficial as if that task had to be done for a thousand users per day, or a million users per day. So if you're spending a lot of time designing the automation and building the architecture and doing all of the necessary parts to actually get the automation or the system created, then you want to make sure that you are able to have that system in place for long enough and in place in the right area of the business so that that investment of time and energy is actually worthwhile to you moving forward.

SPEAKER_01 36:34

What is the difference between building a system and operating it?

SPEAKER_00 36:40

So building the system is a design-heavy process. And when you're building a system, you will have to establish the guardrails that the system needs to maintain throughout the life cycle of that project. When you're operating the system, it requires you to understand where the system might break, where different components might fail, and what those patterns are, and to understand the performance baselines. Like how quickly should I expect this process to complete? How much data should this process generate, and how often, and in what format? That's what an operator needs to be familiar with. And so, as a builder, you might optimize for can this system work? That's going to mean do I have the right tools in place? Am I using the right technologies? Right? If I'm expecting more than a million records inside of my data pipeline, then I can't reliably use, or if I expect more than a million data records over time continuously, uh, or I'm expecting to near a million records, then I can't use Excel reliably because it can only support a million rows. So I need to start thinking about what other solutions, what other data warehouse solutions, what other tools like Power BI can I use to pull that data? Or maybe there's an API that I need to start using to actually pull that data in batches or chunking it. And that might be the best solution for your ingestion uh component inside of your pipeline. If you're doing some really complex transformations on the data, and that transformation is going to happen or needs to happen all the time, or not I won't say all the time, if it needs to happen like in real time, that will require one technology. If it needs to happen in batches, where you can have a delay of like every hour or maybe every day before you generate that report, that requires a different tool, or that can allow you to use a different tool versus having to program a script that can be more on demand. So, and then if you have to store that data somewhere, it matters how often you need to store it, how much of a backup that you need to keep in place, keep on hand. Do you need to store the data daily? Do you need to have backups for the last six months or the last six years? Those questions are very important for a builder to answer because everything that they decide early on in this process is going to affect the operator and affect the reliability of that platform moving forward. And anything that you miss, any steps that you skip that basically require you to rebuild or re-architect the system, could have lasting impacts because, again, you might cause an issue where the operations side of the house are no longer able to handle their business and do the work that they need to do because the system in place no longer supports the the data that's going through it. Or you can get to the point, and I'll say, and you can get to the point where you have to redo work in two weeks that you know you could have avoided if you had just chosen a different technology or chose a different tool earlier on in your process. So understanding that as a builder is in is incredibly helpful. And then operators, they're going to optimize for can this system continue working under the real world conditions. So they're going to be the ones that's going through and making sure that whatever operation is expected to run, it runs properly. They're going to be the ones that need to value evaluate the outcome or the outputs of whatever the system is and make sure that it aligns with whatever the goals are of the business, whatever the risk thresholds are of the business, and whatever other categories that are important for that business. And so that's a different mental model that they have to kind of think about. And that distinction, again, becomes very important at scale. It's not something that you have to think about too much when it's a one or two-person team that is working on very small amounts of business or small operations. But when we're thinking about millions of transactions per second or say millions of transactions per second, even when we get into the thousands and hundreds of thousands, this is something that you have to be mindful about because these decisions are going to have lasting impacts on the business as it grows and move forward. And it can actually limit your ability to grow because you have the wrong technology in place. So even today, I'm working on a very small team with only three developers, and we're working inside of a security governance team. And our main responsibility is to own the security operations reporting workflows, and we only build tools that allow us to do that. And these tools, for the most part, are pretty small. It's uh Office script that can format and process some data or you know do some Excel work. It's a Excel macro that can pull together data from between a few different SharePoint sites. It's a power automate flow that can move a or that can trigger an office script to one process the data and then upload it to some other site for reporting to make sure that we have that full end-to-end cycle without having someone to you know dedicate energy and mental bandwidth to it. And so when we only build tools that we need, it's something that allows us to only focus on the tools that are necessary. And so small teams I would say have an advantage because on a smaller team, the builders are the operators, and so they are intimately aware about every constraint that they have and the context that they have to work in. So they are more likely to make enhancements or prioritize enhancements that actually allow the operation to work better. And it creates, and when they're able to have the skills on the same team that can I'll say on the same team and in the same person, then they're able to create faster feedback loops that allow them to improve. The system more quickly because you can try something today, realize that you ran into a blocker and be able to make a change very quickly for tomorrow to be able to you know do better next time, and you can just continuously learn from that. The challenge with small teams where the builders are the operators is that you no longer have that separation of duties that allows the operations to continue while new development continues, and so you may get caught into the problem where your operations team can no longer improve the system because they're too busy in the weeds build or doing the work, and there's no one to build and think about creative ways to actually actually improve individual components in that system. So depending on the size of your team and the size of the business, is where you can think about how where and how to invest that time and energy and and those resources to actually do the work.

SPEAKER_01 45:10

How deeply should you go into learning a specific technology or skill?

SPEAKER_00 45:18

The trap that many builders fall into is that you'll feel guilt for not mastering every technology or tool that you see inside of the latest uh job descriptions or job postings that you're looking at. But you have to remember that all knowledge is not created equal. And it would be amazing for builders to be able to go super deep into every technology that they're interested in. But that's very unlikely inside of a business environment because the operations and the outcomes that get funded are the ones that actually solve business problems, and a lot of the times business problems are very unique to that specific business, and they might require a very specific tool or a very specific solution that doesn't require you to touch everything that you might be curious about. So I've noticed that even in most of my roles, that the depth that I have inside of a specific topic has really extended to the level of for the problem that I had to solve inside of that role. So I had I learned about the limitations of Excel when trying to import a file that was too big. I learned about the challenges to memory management in threads in Java when I was debugging my health check endpoint and wondering why I was seeing logs from a health check coming in or being tagged to a store manager. And I learned that centralizing the CICD pipelines for our development platform was the best solution because I realized that it was becoming a challenge to keep and upgrade all of the different pipelines for the hundreds of different applications inside of the business when they when each team had their own pipeline inside of their own environment or inside of their own repo, or like where they managed it themselves. So those problems led me to have to do research. That research allowed me to gain some insights, plus seeing the problem, and then going to attempt a solution. That's really how I got the depth, that's how I went through the reps to actually learn the tools and the technologies that I understand today. So a lot of the time, if you want to go really deep into something, you should focus on finding people that are experiencing that problem and make sure you get the projects that are going to you know allow you to go into that topic, whatever the type that topic may be. Because you want you have to understand that the business is going to invest inside of things that it needs. It's not going to invest inside of your passion project just because you're interested in it. If you want to be a pro at something that the business doesn't support, that's going to require you to spend some time and dedicate some energy outside of work, outside of when you actually get your main responsibilities taken care of to go research and do that thing and learn the skill that you want to learn. But again, with the business, the business has its own needs, it has its own goals and its own uh strategy that again may not align 100% with every technology that you are super interested in learning. Right? Most companies don't need to build their own identity and authorized authentication and authorization system for signing in new users, they don't need to build their own password reset uh processes or workflows. They're probably and they probably should and probably will end up using some managed service, managed I am service, and that's good. They should. If you want to learn how to build that thing yourself, you have to actually change companies or be comfortable just building it on your own in a side project. And again, either solution is fine if you want to just learn, but you have to understand what you're learning for and understand the value of the learning that you're going to get.

SPEAKER_01 50:08

And that's all we had for our QA for this week.

SPEAKER_00 50:12

Hopefully, you were able to gain some insights as to the experience from a professional software engineer and what you might expect inside of your role when you go into the field in the industry. If you have any questions about anything that I've discussed, or if you want me to go a little deeper into any of the questions or the answers, definitely again put it in the comments. Let me know what you what you think. If you think any of my takes on these questions were inaccurate, let me know. Uh tell me where I was wrong, what I could kind of improve in the future to make sure that I'm answering those questions more accurately in the future, either on the job or in the interview. So that feedback would be helpful. And then we're gonna jump into our mindset section of the episode for today. So this is a thought that has been coming into my mind persistently over the week. And it's that we all have the same capacity, but we prioritize differently, and that leads to us having different performances. So, yes, we all have the same 24 hours, but the outcomes that we actually experience are going to differ because we all have different ways we invest our attention, energy, discipline, our urgency. And so those differences are going to lead to the outcome that we either don't want or do want. So I want to challenge myself and each of you to before the next time you make a decision on how to invest your energy or your time, which is your most valuable resource, you should think very clearly and deeply about what your priority is. Because that priority is going to be the guidepost that you use to determine how to make that next investment, and without it, it's going to be very difficult to make the best decision for how to invest that time. Because for whatever goal you may have, there may be multiple great options or good options available to reach that goal. But once you start prioritizing your competing goals and saying and ranking, like this health goal is more important than this health goal, or this relationship goal is more important than this financial goal. When you start having that type of ranking in place, then it allows you to make more clear decisions about how to allocate your energy, and you again you can't do that if you have just some type of unclear thing, like I want to do this and I want to do this, and I'm gonna do this. You have all these targets that are kind of pulling you in different directions. You may not end up being able to focus on the right thing that you need to at this current moment because you are going in so many different directions, and I will say it's and again, it's based on you and what you want. Again, the priority is based on your values and whether or not you value one thing over the other or with another. And again, you have the capacity, same 24 hours, so you could figure out that hey, you value all these things, you could figure out a batch some project processes in your life, you could figure out how to you know put off some things you may not have to focus on this goal this month, maybe it might be a two months from now goal. That could be the thing, but having and taking that step to prioritize it and understand and look into your own values is going to be extremely helpful to you for any of your next steps moving forward. So just keep that in mind. Again, I challenge you to do that step and take that step. It takes some time, some it takes some self-reflection, it takes some you know, peace and space in your life, it takes a moment that you have to invest. But I think it's definitely worth us all investing into it. And that's all we had for this week. Uh, thank you everyone for tuning in, and I appreciate your time, I appreciate your energy and your attention. I hope this session, this space, this conversation has been valuable to you and can allow you to grow in all the ways that you want to grow. Some quick announcements before we jump out of here. I do want to say happy birthday to the birthday club for this week. Uh, Gavin, happy birthday to you. You are a young man, you are growing, you are becoming the man that you gotta be. So continue to do the work that you need to do, continue to be the person that focuses on the thing that needs to be focused on. And good luck to you and all of your endeavors and all of your goals. I hope I love to see you uh soon. I would love to see you very soon, and uh just good luck growing into the young man that you gotta be. Happy birthday to my auntie Melissa, uh definitely a great person, my goodmother and my aunt, actually, right? Uh thank you for all of the support that you give to me. Thank you for the love, the kindness, and happy birthday to you. Uh I hope you are feeling great this year. I hope you are growing and growing healthily, growing happily, growing in the way that you want to grow. And I hope you are able to look and reflect on your life and just feel peace and happiness and joy and everything that you have built and all the things and people that you've invested time and energy into. And happy birthday to my pops in law. You've been my pops in law for uh a little over a year now, and I'm glad to have you as the person to join or to one of the people to that have joined into the family. Uh, you are an amazing person, you are very funny, you are very intelligent, and you are a great man to uh you know, you are a great man to kind of learn from, especially as I'm you know, be trying to be my best to become the man that your daughter needs to, you know, just or basically just needs and wants. So uh happy birthday to you. Continue to be the man that you are, continue to do the great things that you do, and I will see you very soon. And again, happy birthday. Hope you're feeling great, hope you're feeling youthful. Uh but you're getting old. So don't do nothing crazy. Uh, and happy birthday to my cousin-in-law. I wonder if that's like a thing for real. But happy birthday, Rob. I don't I don't know, I don't know how old you are turning, but I hope you are feeling great. I hope your body is healing. I hope your mind is growing. I hope all the goals that you and Lynette have this year are being met or at least on track to be met when you want to meet them. Good luck to you and all of those goals, whatever they are. And yeah, just happy birthday. Hope you're feeling great. So that's what we have for this week, and happy birthday again to all of the birthday people. Uh, more life, more happiness, more success for you in this year and every year after. And the peace out to the community, peace out to the family, peace out to the universe. I hope everybody enjoys this next week. We are definitely getting into that warm weather. So, uh, you know, stay safe, stay hydrated, stay cool whenever possible. I will see y'all in the next one. Katie out of here.