Living In Tech

Technical debt is one of the most misunderstood risks facing businesses today. It quietly accumulates in the background — in the software systems, integrations, and processes that organizations depend on every single day. Left unaddressed, it does not stay quiet for long. What Is Technical Debt, and Why Should Business Owners Care? Technical debt is the accumulated cost of shortcuts, workarounds, and deferred maintenance in a technology system. It is the result of choosing the fast path over the right path — again and again — until the shortcuts become the system itself. For business owners, the impact is felt long before the IT team raises the alarm. Development takes longer. Projects cost more than expected. Simple changes require weeks of testing. New tools get purchased to manage problems that are really symptoms of something deeper. The system becomes harder to explain, harder to maintain, and harder to trust. Think of it like a house. A small crack in the foun...

UPDATE: This is only an issue in the "Old Designer". If you moved to the "New Designer" the actions still appear. I would recommend moving over to the new designer, since Microsoft is depreciating the old designer. A recent change to the Microsoft Dataverse connector in Power Automate has left many flows broken or incomplete. The familiar Get a row by ID and List rows actions appear to have been removed from the connector's action picker in multiple environments — and the issue is reproducible across different browsers and machines, ruling out a caching problem. In their place, a new Search rows (preview) action has been introduced. This post documents the behavior and a working workaround for restoring Get a row by ID functionality using the Power Automate Tools Chrome extension. What Changed When adding a new Dataverse action to a Power Automate flow, the expected actions — Get a row by ID, List rows, and others — are no longer available from the a...

Software development is, at its core, a discipline that demands sustained, uninterrupted concentration. Unlike many other professional roles, writing and reviewing code requires developers to hold large amounts of context in working memory simultaneously — the logic of a function, the state of a variable, the downstream effects of a change. When that concentration is broken, the cost is not simply the time lost to the interruption itself. It is the time required to reconstruct that mental context from scratch. Research from the University of California, Irvine found that information workers spend an average of just 11 minutes in a focused working context before being interrupted or switching tasks — and that it takes an average of 25 minutes to return to the same task afterward. For software developers, where deep concentration is not optional but essential, those numbers carry serious implications for productivity, quality, and team morale. The Hidden Cost of Fragmented Developer ...

When working with software development teams — whether as a developer, architect, or technical manager — one pattern tends to surface repeatedly in inherited or long-running projects: the monolithic solution. Everything lives in a single Visual Studio solution file, regardless of whether the code targets different runtimes, serves different purposes, or is deployed to completely different environments. The intent is usually convenience, but the long-term cost is significant. This post outlines why splitting code into separate, purpose-driven repositories is the better approach — and why mixing .NET versions in a single solution in particular should be avoided. What Does a Monolithic Solution Look Like? A monolithic solution in the .NET world typically includes a mix of project types under one solution file (.sln). For example, a Dynamics 365 / Power Platform project might contain: Plugins targeting .NET Framework 4.6.2 Azure Functions targeting .NET 8.0 (or even .NET 10.0) C...

When setting up a Proxmox VE environment it is common to end up with a node named pve , which is the default hostname assigned during installation. This becomes a problem when managing multiple Proxmox servers since every node will show up as pve in the web UI. This post covers the complete process for renaming a Proxmox node to a meaningful name including the FQDN, and how to handle the pmxcfs filesystem quirks that make this more involved than a standard Linux hostname change. Understanding How Proxmox Uses the Hostname Proxmox VE derives the node name directly from the short hostname (the part before the first dot). This means a server configured with the FQDN pve-node-1.example.lan will appear in the UI as pve-node-1 . It is important to plan the naming convention carefully upfront. A naming scheme like pve-node-1 , pve-node-2 works well because the short hostname is already fully unique, without relying on the domain portion to differentiate nodes. Proxmox stores its ...

As part of our routine monthly maintenance on Azure Functions, we update NuGet packages to stay current and pick up bug fixes. This month that process led to a breaking change when we upgraded Microsoft.ApplicationInsights.WorkerService from version 2.23.0 to 3.0.0 on our .NET 8 Azure Functions. After the upgrade, our Application Insights logging stopped working entirely. Telemetry was no longer being captured, and it became clear that the dependency injection configuration in our Program.cs was the culprit. Here is what we had and how we fixed it. The Problem In version 2.23.0, we configured Application Insights in Program.cs like this: public static void Main(string[] args) { IHost host = new HostBuilder() .ConfigureFunctionsWorkerDefaults() .ConfigureServices(s => { s.AddApplicationInsightsTelemetryWorkerService(options => { options.EnableAdaptiveSampling = false; }); s.ConfigureFunc...