Living In Tech

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...

 If you have worked with Power Pages using the Enhanced Data Model, you know the pain of manually adding all the site components to a Dataverse solution.  It's tedious, error-prone, and frankly, there are a lot of components to track down.  You need to add the site record, the site languages, and then every individual component — Web Pages, Web Templates, Content Snippets, Site Settings, Table Permissions, Basic Forms, Advanced Forms, and more.  Miss one and your deployment won't work as expected. To solve this problem, we built an open source .NET console application called PowerPages.SolutionComponents.Console .  This tool automates the entire process of discovering and adding all Power Pages site components to a Dataverse solution in one shot. What Does It Do? The tool connects directly to your Dataverse environment and does the following: Adds the Power Pages Site record to your solution. Finds and adds all related Power Page Site Languages. Finds...

If your marketing team lives in HubSpot and your sales team lives in Microsoft Dynamics 365, getting those two platforms to reliably share data is one of the most important integration decisions you'll make. There are two main paths to connect them: a native connector available directly in the HubSpot App Marketplace, or a custom-built integration using Azure Functions. Choosing the wrong one can mean months of frustration. This post walks through both options in detail so you can make the right call for your team. The Native HubSpot Connector The Microsoft Dynamics 365 integration is a first-party app built and maintained by HubSpot, available in the HubSpot App Marketplace and Microsoft AppSource. It's powered by HubSpot's Data Sync engine — part of Data Hub (formerly Operations Hub) — and supports bidirectional sync across 12 object types: Contacts ↔ Leads / Contacts Companies ↔ Accounts Deals ↔ Opportunities Products ↔ Bundles Meetings ↔ Appointments Task...