In this video I break down what “automation” actually looks like in a real software engineering day—not just writing scripts, but the meetings and decisions that make automation possible. I walk through a requirements meeting where we get super specific about a seemingly simple feature (sending a notification): timing, content, language, app version compatibility, and how the backend/platform work needs to line up with what the frontend can render. That’s the part people forget: a lot of our job is problem solving first, and then we automate the process we decided on. I also talk about the “set it once every couple years” infrastructure tasks—domains, SSL certs, queue configs, Lambda/server settings—and why they’re perfect candidates for automation after you’ve thought through the right configurations. From there I explain two big automation pillars: infrastructure as code (handing a config/template to AWS/Azure/IBM Cloud/etc. to provision resources) and CI/CD (automating builds, tests, and deployments from GitHub to the cloud). The takeaway is ROI: automate repetitive, low-thought work so you can focus on architecture, design, and the big idea—while still being careful, because automating the wrong thing (or trusting it blindly) can create security and reliability risks.