While this was certainly true for C# that was written a decade ago, that is no longer the case with frameworks like .NET Core. Hate it all you want, but no other language does async/await as well as C#. Its ubiquitous in C# unlike all other languages out there. It's surprisingly easy and concise to write but doesn't come with the performance penalty associated with languages like Python. It also runs without any hiccups on Linux now. The only thing that seems to work against it, is it's reputation.

I work in a primarily C# shop. I am often quite annoyed at some of coworkers code due to it being what I feel is needlessly over abstracted. I don't know if it's my lack of experience with this style of code, or perhaps I don't know the concept of OOP as well as I should. But it is quite aggravating.

Abstraction if necessary but not necessarily abstraction. That's my rule of thumb.

I think it's the frameworks. If you are using something like .Net Core it really encourages you to break everything up into services that can be selected via dependency injection and you naturally seem to end up several layers.

I'm sure there are times when that's absolutely the way to go, but something simpler that solves the problem directly will often do.

The way Asp.net encourages inscrutable code through spooky action-at-a-distance dependency injection patterns is one of the things I actively dislike about working with C#. Fortunately, you can avoid most of it and be more explicit if you want, it's just not the idiomatic way. There's almost always an escape hatch to ditch the overblown abstraction layers and get down to what's actually happening.

If all else fails there's dotPeek and Reflector...

And thus killing of the ability to do proper unit testing.

If that pattern is required for proper unit-testing, I don't want to do 'proper' unit testing.

You can write code where your dependencies are injected and can be swapped out for testing without buying into a framework that makes it that difficult to reason about what code is actually being run and in what order.

I don't have experience with .NET core but taking example of Spring in Java (which gets targeted a lot for this sort of thing), you can get away with putting the logic at the outer levels without using services. However, more often then not, you end up using similar chunks of related functionality that then gets put into some common class to avoid repeating it everywhere. If you are already doing that, then why not put them in a service - its just a class with a @Service annotation that the dependency injection can take advantage of. Further, the fact that services are logical containers of such related functionality, creating them actually follows the principle of least surprise (viz. audit related stuff goes in AuditService) and testing/mocking etc becomes cleaner.

Of course, if you are writing a simple utility, then none of this is necessary - you'll probably not use Spring for it anyway and just core Java is fine.

whereby the only injection ususally is the same servuce over and over. with the occassional DatabaseMock sometimes...

Unit testing is not "sometimes" is 50% if the code you write

in your dreams maybe :-)

(not to say that this wouldnt be a good thing)

I’m curious how many are still using WebForms or the new equivalent? Then claim they know C#

Most of my experience is in C++ and C#. I adore C#... but I agree: it’s as though developers have difficulty getting to the task at hand when using it.

Maybe it’s because attempting even simple abstractions in C++ can foot-gun yourself in some esoteric way? In comparison, the cost to build unnecessary abstractions is lower in C# so many live on.

The ability to gauge the right level of abstraction is the mark of a good developer.

That being said I rather rework an over abstracted C# codebase then a hyper templated , singleton using, multiple >5 inheritance, no STL, void pointing C++ madness.

I never wrote, and will never write, in my resume that I have a good amount of experience writing COBOL for AS400 :)

These systems in my country are still used a lot. Go to a store, look behind the counter and you will see Windows 10 with opened only a maximized window of a green/black terminal connected to an AS/400. I've seen it even on store opened this year! And as they tell me programmers are even well paid since more and more retire every year and the young one doesn't know these systems.

The funny thing is that I'm not even that old, reading my initial comment you would think I'm talking about the 80s or 90s, but I got my experience with COBOL in 2009-2013 (not 4 years straight, I did other stuff too) when working at an insurance company. At the time almost the entire company was run from a few AS400 (and A LOT of office-people doing insurance stuff, of course).

You are probably not getting paid your worth then, experience with these is gold and all the new upstart programmers can't even compete with you on the high-paying jobs that rely on this knowledge.

Im not sure thats true. Last year when the unemployment systems got overwhelmed, I read a state was desperate for cobol developers and was offering some laughable salary. Searching for 'cobol developer average salary' seems to confirm it's not worth much.

These systems are now so old that the only people running them are those that have consistently under-allocated resources to IT. Penny pinchers arent known for paying out huge salaries to people.

Much more likely they'll continue paying as little as possible, and then award a huge contract to Oracle et al to rewrite it when they cant find anyone.

The state might be, however they’ll likely contract the work out and the company who’ll pick it up will pay a lot especially if they taking on that specific contract to get their foot in the door.

You also have a lot of financial institutions, insurance companies, health providers and big retail/manufacturing companies that have a lot of legacy systems and they pay quite well.

I don’t know about that specific case but quite often government institutions are locked into salary tiers they can’t offer more nor do they actually expect to find anyone for that position it’s just often a requirement proper to issuing a tender.

Basically it goes like this “we tried and we can’t find anyone for $56,000 per year to fix our system, we issued a tender and got proposals for $350-400K so that’s the budget we need”.

That's fine, I'm not optimizing my life for money. I'm glad I don't have to deal with IBM mainframes anymore.

I suppose that is fair, though I still think the skillset is a valuable and marketable skill worth noting you have. I work in an environment that has both IBM mainframe and modern technologies, and familiarity with both would presumably count as an asset.