This post is ridiculous, but there is a point hidden under the ham-fisted writing.
.net development is complex. The languages and frameworks are deep, and cargo cult (implementing without understanding) development is common. .net provides you, out of the box, with a collection of pretty good "easy-mode" APIs; and most (as far as my personal experience has taught me) .net developers are exclusively familiar with them. The more dedicated of us learn how things work under the covers; but using that understanding to full effect can often result in fights with management (and team members) on smaller and less experienced teams (where your code is "unreadable" by other team members).
I love .net, one of the reasons I love it is that if there's something you don't love about it, you can replace it. It's written in such a way as to encourage you to replace it's components in whole or in part for your specific needs; and it provides you with fantastic tooling to do so. Replacing and extending the framework well requires experience and discipline, without them you'll make a mess (and everyone on your team has a horror story about someone else's mess). Gaining that experience and discipline requires fastidious dedication, and a very understanding employer.
I don't see this as a weakness in the platform, although it is a daily frustration on a lot of projects. Extending the framework for your project requires writing framework complexity code in your project.
The potential for complexity runs deep. You could, for example, easily interop with some custom c++ that calls custom assembly (as an extreme, borderline silly example). When your coworkers see that, and their first reaction is "If this guy gets hit by a bus, I can't maintain that", they are justified to be frustrated. It's up to you to prove that it's needed more than they are frustrated; or to take it out. I think that argument is healthy.
Dapper (a popular mini ORM) does a ton of run-time custom generation and execution of intermediate language. It's the right solution, and well executed, but if you tried doing that in your own project, you're likely to have a fight on your hands. Your coworkers would likely have no problem adding Dapper to your solution because they won't be expected to maintain the code, but as soon as they feel they may be stuck maintaining something so difficult to understand they are likely to want to murder you.
As a former architect on one of the most trafficked .net platform web applications on the internet, I've seen .net do some amazing things. I've made it do some amazing things. .net is predictable and super hackable (and it wants you to hack it); but you have to get the money-man and your team's trust before you can do any of that hacking.
You can be a good .net developer. It's not easy, but it is rewarding.
I am in the same camp. I'd prefer to know an older technology (and it's underpinnings) completely than scratch the surfaces on a bunch of short lived new ones. Most of the new stuff I see is pretty high level. I invest my free time in getting as close to the metal as I can.
If there's something new with a feature I like, I'm a lot more likely to try to replicate their feature in something I know than make a switch.
"Poorly engineered" and "over engineered" are different.
If the solution is running slow for no good reason it's poorly engineered. If it's unnecessarily difficult to implement it's poorly engineered. If it eats up too much memory because it does more than you need it for it's poorly engineered. If it's taking too long to create, it's poorly engineered.
In my experience I hear the term "over engineered" used by bitchy architects to describe components that have none of these problems, but are built, under the covers, using features of the underlying system or techniques that are unfamiliar to that architect. I hear it used to cover insecurity on teams containing members of very different skill levels.
If it's a problem, call it poorly engineered and get it fixed; if it's not a problem and you just can't read it, hit the books or get out of the way. The term "over engineered" just worries the suits, and does no good.
I am doing just that. A hugely ambitious project, with a very wide potential user base, but I have lost all hope in finding funding at a reasonable rate. I am consulting during the day to pay for what I need, and working on the product at night.
.net development is complex. The languages and frameworks are deep, and cargo cult (implementing without understanding) development is common. .net provides you, out of the box, with a collection of pretty good "easy-mode" APIs; and most (as far as my personal experience has taught me) .net developers are exclusively familiar with them. The more dedicated of us learn how things work under the covers; but using that understanding to full effect can often result in fights with management (and team members) on smaller and less experienced teams (where your code is "unreadable" by other team members).
I love .net, one of the reasons I love it is that if there's something you don't love about it, you can replace it. It's written in such a way as to encourage you to replace it's components in whole or in part for your specific needs; and it provides you with fantastic tooling to do so. Replacing and extending the framework well requires experience and discipline, without them you'll make a mess (and everyone on your team has a horror story about someone else's mess). Gaining that experience and discipline requires fastidious dedication, and a very understanding employer.
I don't see this as a weakness in the platform, although it is a daily frustration on a lot of projects. Extending the framework for your project requires writing framework complexity code in your project.
The potential for complexity runs deep. You could, for example, easily interop with some custom c++ that calls custom assembly (as an extreme, borderline silly example). When your coworkers see that, and their first reaction is "If this guy gets hit by a bus, I can't maintain that", they are justified to be frustrated. It's up to you to prove that it's needed more than they are frustrated; or to take it out. I think that argument is healthy.
Dapper (a popular mini ORM) does a ton of run-time custom generation and execution of intermediate language. It's the right solution, and well executed, but if you tried doing that in your own project, you're likely to have a fight on your hands. Your coworkers would likely have no problem adding Dapper to your solution because they won't be expected to maintain the code, but as soon as they feel they may be stuck maintaining something so difficult to understand they are likely to want to murder you.
As a former architect on one of the most trafficked .net platform web applications on the internet, I've seen .net do some amazing things. I've made it do some amazing things. .net is predictable and super hackable (and it wants you to hack it); but you have to get the money-man and your team's trust before you can do any of that hacking.
You can be a good .net developer. It's not easy, but it is rewarding.