When you deploy an AWS Lambda function, you choose a memory allocation. AWS scales CPU and network proportionally to that memory setting. Most teams pick a number—512 MB, 1024 MB, maybe 2048 MB—and move on. The function works, so the setting never changes. A year later, you are paying for memory the function never uses, or the function runs slower than it should because you chose conservatively and never revisited the decision. I have done this. I have deployed Lambda functions with 1024 MB of memory because it felt safe, only to discover months later that the function used 200 MB at peak and completed in half the time when I reduced the allocation to 512 MB. I have also under-provisioned functions, then spent time investigating timeout errors that disappeared when I doubled the memory and gave the function more CPU. Right-sizing Lambda memory is not a one-time configuration decision. It is an ongoing operational practice that requires measurement, not intuition. The cost differen...
When you inherit a legacy .NET system that needs modernization, the instinct is to read the code until you understand it, then write tests. That sequence is backward. If the system works in production, you need to lock down its behavior before you refactor anything, and you need to do it without knowing why the code does what it does. Characterization tests solve this problem. They document observed behavior, not intended behavior, and they catch regressions while you're still learning the system. I've used characterization tests to modernize several legacy .NET systems where the original developers were gone, documentation was sparse, and the only source of truth was production. The goal was not to prove the code was correct. The goal was to prevent silent breakage while I replaced tightly coupled classes, swapped out WCF endpoints for REST APIs, and introduced dependency injection. Characterization tests are the safety net that makes incremental modernization possible. T...