Agree these warnings are pretty annoying in a project that didn't start out using nullable ref types correctly from the start. I have a large project in this situation, and fixing all these warnings is pretty daunting, requiring significant rework and refactoring. But I've come to see the value of using nullable ref types, so I've adopted it in smaller projects, and have been using it going forward. It's just not feasible to retrofit in all cases.

I have this feeling with some regularity. In your case, I'd wonder what exactly you're working on or trying to. I'm very familiar with the feeling of having bitten off more than I can chew, the dread of things getting gradually more complicated and fragile. Yes it is all a creative endeavor.

I use NuGet quite a bit. I think carefully about what dependencies are worth adding to a project. I'll never add a package carelessly. I think being productive in .NET means using NuGet packages wisely. If you want to be a senior or principal level developer in a typical corporate environment, it's not a good use of your time to re-invent stuff like logging or an IoC container or security/authorization IMO. There is a time and place for doing low-level invention when it helps you think through a fundamental problem, and get some insight or appreciation for how certain low-level services work. ORM is a good example, and one area where I'm a hypocrite. (This came from legit unhappiness with Entity Framework.) >>Sometimes someone refers me to a package from some developer, and I think "What's in this? Is it secure? What benefit do I get from adding another assembly versus use code I already have?<< Certainly it depends on the package, but I think you have to be honest with yourself about how much time you have and how much you're trying to achieve. I would be very surprised/skpetical if a lone developer believes he has code already written for every single problem he encounters. Just yesterday I was implementing html email. This typically requires inlining CSS because typical mail clients don't respect stylesheets. A package like Premailer.Net makes this very easy. There is no reason to invent this myself. I could think of a dozen situations like this. I have a few NuGet packages myself, as there are a few areas where I was truly unhappy with the status quo and wanted to offer my own solution. But I've made quite a number of ridiculous packages also, if you go through my public packages. (They are a bit hard to delete on NuGet.org.)

I remember the moment I wrote my first ever function (1994) in what was then called Access Basic. I had taken one class in Turbo Pascal up to that point, but didn't understand it. I was handy with spreadsheets and understood what functions were. But I was trying to bridge over to databases, and everything looked strange. I don't remember what my function did, but I remember straining to understand how to solve a certain problem I was having at the moment, then having a flash of understanding how a function would help me. I distinctly remember getting up to take a walk around the building on my college campus where I was. I don't really have a victory ritual as such these days. It feels like every victory comes a dozen more action items.

I still mainly like OO stuff (as a .NET/C# dev), but I can't say whether your project would benefit from the refactoring you considered. If your gut says no, then I believe you. I come across useful inheritance examples occasionally, so I don't understand inheritance hate. Like any language feature it can be abused. My examples are often abstract classes that therefore require another class to implement/inherit abstract methods. For example, I work on stuff that I want to work equally well in a local file system and Azure blob storage. There is some common behavior that goes in an abstract base class, followed by some subclass capabilities that are environment-specific. From the .NET BCL, Streams follow this pattern. Streams are abstract, with a gaggle of concrete implementations for different situations. I don't see what's wrong with that. Now, I've seen inheritance diagrams like the old C++ MFC stuff that were over-the-top complicated. I think they had reasons at the time, but that was then. I would say that most of the intellectual heavy lift in app development (in my world) is database design, data modeling -- understanding stakeholder requirements and translating them into relational models. I would agree this doesn't really fit an OO paradigm very well, and I don't see that it needs to. For example, I don't think inheritance translates very well in relational terms except in one narrow situation. I usually have base class to define user/timestamp columns like `DateCreated`, `CreatedBy` and so on -- and my model classes (tables) will inherit from that base class in order to get those common properties. But that's really it. In the app space, it seems like 80% of dev effort goes into building CRUD experiences (forms and list management) of one kind or another. The other 20% is "report creation" of some kind or another, in my world. I don't think there's a perfect distinction between the two, but I would agree there's not really any OO magic in this layer. OO doesn't really make this experience better, IMO. We do have endless battles over UI frameworks and ORM layers. (I'm getting behind Blazor in the web space, and I have my own ORM opinions for sure! Another topic!) I'm not sure why anyone would challenge the need for abstraction and encapsulation, but there certainly trade-offs and a need for balance. I like this talk (The Wet Codebase by Dan Abramov – Deconstruct[

Although I've been mainly interested in Blazor server so far, I'm really excited about this tech because I never liked the JS experience. I have no idea if it will catch on, but I really hope so -- whether in server or WASM form.

I have a homegrown ORM called Postulate that is built around Dapper, with a CP article here in fact: Intro to Postulate ORM[^] This article is a bit out of date as I actively work on it here: [^] I completely agree that EF is too complicated, and in particular it's the Migrations feature I have found really painful. (In fairness, my gf uses it at work, and she has no real issue with it. I guess your mileage may vary.) I think ORM is neat area to work in, and I simply have a lot of passion for it. I've found it a really interesting challenge to balance simplicity and power. Dapper makes a lot of good things possible -- I'm a huge fan of Dapper. I admire Dapper.FastCrud (I think it's called), it's another ORM built around Dapper as the name suggests, and I sort of envy the simplicity they achieved. I do a few extra things to support code-first and some special tooling to generate database tables from model classes. I've actually never used Linq to SQL, but I hear lots of praise for it.

I certainly don't mind the idea of them (e.g. place to put connection strings and other straightforward config stuff), but I agree they are mysterious and verbose in other areas.