Changing APIs is a common problem for library authors. There’s some class or function that you need to change, but you don’t want to break your library’s client code when they upgrade the library. In other words, the change needs to be backward compatible. Sure, there are cases when you’ll have to make breaking changes, but it’s usually better to avoid that. In the case of company-internal packages, when you can modify both the library and the app that consumes it, there are a few nifty patterns to deal with API changes.

We all know the value of debugging. Inspecting the values of variables, seeing the call stack, and moving step-by-step are all features that are priceless for developers. But it’s not always simple to get a debugging session going in real-world scenarios. Sometimes, you can’t get the debugger working. Or you’re starting the program from the command line and want to debug from the very start. Perhaps there’s a crash as soon as the app starts.

I’ve been a .NET software developer for my entire career, and I love it. I love the C# language, the productivity of the platform, and the ecosystem. But I’ve been dealing with an existential crisis for years now. I see how companies, especially startups, don’t seem to choose .NET as their platform of choice. That role seems to be reserved to Node.js in recent years [1] [2] [3] . Over the last few years, I got to work with Node.