Updates to About page

Draft posts
Config page changes

Author: ATXcoder

_config.yml

@@ -21,7 +21,7 @@ title: Codes with Coffee # the main title
 tagline: Building things one sip at a time. # it will display as the subtitle
 
 description: >- # used by seo meta and the atom feed
-  Blog site for Thomas Sloan, the Elder Dev Guy
+  Blog site for Thomas Sloan, Codes with Coffee
 
 # Fill in the protocol & hostname for your site.
 # E.g. 'https://username.github.io', note that it does not end with a '/'.

_drafts/automation-checklist.md

@@ -0,0 +1,94 @@
+---
+title: The Automation Debt Checklist
+description: The questions I as before building, approving, or inheriting any automation
+categories: [Automation,Architecture]
+tags: [automation]
+---
+
+Most automation doesn’t fail loudly.
+
+It keeps running.
+It keeps “working.”
+And over time, it quietly becomes something no one fully understands, owns, or feels confident changing.
+
+This is automation debt.
+
+It builds when automations are created quickly, ownership is unclear, assumptions go undocumented, or “temporary” solutions become permanent. Individually, these choices seem reasonable. Collectively, they create systems that are fragile, risky, and expensive to maintain — even if nothing appears broken yet.
+
+I’ve seen this pattern repeatedly in enterprise environments:
+automations that save time in the short term, but create confusion, security concerns, or operational risk months or years later.
+
+This checklist isn’t about discouraging automation.
+It’s about building it with intention.
+
+The questions below are the ones I use when:
+
+ - Reviewing an existing automation
+
+ - Inheriting a flow someone else built
+
+ - Deciding whether something should be automated at all
+
+You don’t need to answer “yes” to every question.
+But unanswered questions are often where debt starts to form.
+
+Grab a cup of coffee, work through the list, and treat it as a conversation — not a compliance exercise.
+
+The goal isn’t perfection.
+It’s clarity.
+
+---
+
+## Before You Automate (Pre-Build Sanity Check)
+
+- Is this solving a process problem, not a people or policy problem?
+- Can this process be explained clearly without diagrams or code?
+- Would this still make sense if the original author left tomorrow?
+- Is automation actually cheaper than fixing the root cause?
+
+If you can’t answer these confidently, automation will amplify the mess.
+
+## Ownership & Accountability
+
+- Is there a named owner (not a team, not “IT”)?
+- Does the owner understand what the automation actually does?
+- Is ownership documented somewhere outside the tool itself?
+- Is there a review cadence (quarterly, biannual, annual)?
+
+“Everyone owns it” usually means no one does.
+
+## Change & Dependency Risk
+
+- What breaks if a connector, API, or data source changes?
+- Are assumptions about data formats documented?
+- Is there alerting for silent failures?
+- Can this be safely disabled without causing business impact?
+
+## Security & Identity Smells
+
+- Is this running under a shared account or service account?
+- Does it have more permissions than it needs?
+- Would a security review raise questions you can’t answer?
+- Is credential rotation documented?
+
+Automation often becomes “invisible admin access.”
+
+## Scale & Performance Reality Check
+
+- What happens if volume doubles?
+- Are retries controlled or uncontrolled?
+- Is throttling understood and accounted for?
+- Has this ever been tested under real load?
+
+## Documentation & Maintainability
+
+- Can someone new understand this in under 15 minutes?
+- Are business rules documented in plain language?
+- Is logic discoverable, or scattered across conditions?
+- Is there a clear reason this automation still exists?
+
+Final Question (Most Important)
+
+- If this broke silently for a week, would anyone notice?
+
+If the answer is “maybe” — you already have automation debt.

_drafts/spotting-automation-technical-debt.md

@@ -187,7 +187,3 @@ It doesn’t make you nervous to open it.
 
 If you’re afraid to touch a workflow…  
 **It’s already technical debt.**
-
----
-
-Want a checklist or a follow-up on **refactoring automation safely**? Just ask.

_tabs/about.md

@@ -4,4 +4,20 @@ icon: fas fa-info-circle
 order: 6
 ---
 
-Hi, I’m Thomas! I’m a IT Solutions Architect, SharePoint SME, AI evangelist, and a lifelong tech tinkerer who loves coding, automation, and exploring the latest in AI. I spend my days building solutions with Power Automate, Laravel, Node-RED, n8n, and other tools to make work smarter, not harder. On this blog, I share tutorials, insights, and tips for developers, IT pros, and anyone curious about how technology and AI can simplify real-world problems. When I’m not immersed in code or AI experiments, you’ll find me gaming, cooking, or hanging out with my family.
+Hi, I’m Thomas.
+
+I’m an IT Solutions Architect with over 15 years of experience designing, deploying, and supporting enterprise automation platforms in real-world environments. I’ve spent most of my career building, inheriting, fixing, and maintaining systems that were meant to make work easier — and learning firsthand which ones actually do.
+
+I work with tools like Power Automate, Power Apps, SharePoint, PowerShell, and AI-assisted workflows, helping teams automate everyday processes without quietly creating long-term technical or operational debt.
+
+Codes with Coffee is where I step away from slide decks, vendor hype, and “perfect world” demos. This site is about practical automation — the kind that has to survive changing requirements, staff turnover, security reviews, and the reality of production systems that grow over time.
+
+You’ll find two kinds of content here:
+
+ - Hands-on tutorials — step-by-step guides for building useful automations, templates, and flows (like automating out-of-office replies or creating repeatable Planner setups).
+
+ - Architecture and governance insights — lessons learned from seeing what works, what breaks, and what slowly becomes a problem months after something ships.
+
+My goal is to help developers and IT professionals build systems that are understandable, maintainable, and still make sense six months from now — not just systems that technically “work.”
+
+When I’m not building or reviewing automations, I’m usually experimenting with new tools, gaming, cooking, or spending time with my family — almost always with a cup of coffee nearby.