3 ms·

Every C# project (and programmer) I've ever worked with has been obsessed with "Enterprise" code laden with boilerplate, excessive use of design patterns, and h

Every C# project (and programmer) I've ever worked with has been obsessed with "Enterprise" code laden with boilerplate, excessive use of design patterns, and hundreds of tiny 3 line classes that force you to jump around in the editor. Generally these projects are not fun to work on and having colleagues that spend significant chunks of time "refactoring" or talking about refactoring is not fun. Even saying this is going to open a bunch of sealioning from these types ( https://knowyourmeme.com/photos/873260-sea-lioning https://knowyourmeme.com/photos/873260-sea-lioning) but that's just my experience. C# has pretty good support for lambdas and implicitly typed variables these days, so a lot of the enterprise stuff is overkill. Implementations in C# could look more like Python while being more type safe but they tend not to.

jerriep 6y ago
I'm a long time .NET developer and I love the framework, language (C#) and developer tools (I use Jetbrains Rider). However, if there is one thing I have to find that I do not like it is this. It is extremely common to find over-engineered .NET codebases, and the developers will just blindly follow some best-practices document from Microsoft without asking themselves whether all of it is necessary. I once had a developer commenting on one of my blog posts who was very angry that I did not use a proper layered architecture in the blog post :)
- bharam 6y ago
  One does not simply retrieve a record from the database. One must first declare a type to represent the database's view of the record and copy it into a repository layer. Next a type shall be declared to translate the repository's view of the record to a domain layer. Another type shall translate the domain layer's view of the record to the controller layer's view...and so on.
dynamite-ready 6y ago
I've been working at a .Net shop for the past year. There a tendency to see encyclopedic knowledge of OOP design patterns almost as a form of currency. C# itself is an ok language. It's just the culture around developing web applications with .Net that's painful. At my workplace, we're currently transitioning from C# to Typescript. As you can imagine, it's not pretty. Key to this is how Microsoft have managed to encode much of the misdirection inherent in .Net webapp development, into the Azure API surface. I dunno... Now I sound as dogmatic as the community I'm accusing of dogmatism...
- decafninja 6y ago
  I am curious how that C# -> TypeScript transition is going, and how it is structured. I was in a project that involved a team of mostly traditional enterprise .NET devs writing a greenfield app in Python (language choice mandated from up top). The result was basically something that was designed like a dogmatic enterprise .NET application, only using Python abused and wrangled to fit that style. After that project was done, for subsequent work, the team split into two camps - one camp that despised being forced to work with Python and continued to write Python in enterprise .NET style, and one camp that decided to explore more about Python and try working in more "Pythonic" style. Code review sessions were full of emotions and drama. Pretty much everyone in the first camp eventually left, either for other internal teams that were still working in .NET, or for other companies.
  - dynamite-ready 6y ago
    Yes. This sounds a lot like my current experience, except for the language involved (TS in my case) and the team split (I'm the one with less .Net experience). I like to think I'm experienced enough to see it as a valuable opportunity to learn something that's not just about code and product... Anyway, everything else you mentioned sounds uncannily similar. Makes you wonder how such a culture develops. The only constant appears to be Microsoft development tools, curiously.

jerriep 6y ago

I'm a long time .NET developer and I love the framework, language (C#) and developer tools (I use Jetbrains Rider). However, if there is one thing I have to find that I do not like it is this. It is extremely common to find over-engineered .NET codebases, and the developers will just blindly follow some best-practices document from Microsoft without asking themselves whether all of it is necessary. I once had a developer commenting on one of my blog posts who was very angry that I did not use a proper layered architecture in the blog post :)

bharam 6y ago
One does not simply retrieve a record from the database. One must first declare a type to represent the database's view of the record and copy it into a repository layer. Next a type shall be declared to translate the repository's view of the record to a domain layer. Another type shall translate the domain layer's view of the record to the controller layer's view...and so on.

dynamite-ready 6y ago

I've been working at a .Net shop for the past year. There a tendency to see encyclopedic knowledge of OOP design patterns almost as a form of currency. C# itself is an ok language. It's just the culture around developing web applications with .Net that's painful. At my workplace, we're currently transitioning from C# to Typescript. As you can imagine, it's not pretty. Key to this is how Microsoft have managed to encode much of the misdirection inherent in .Net webapp development, into the Azure API surface. I dunno... Now I sound as dogmatic as the community I'm accusing of dogmatism...

decafninja 6y ago
I am curious how that C# -> TypeScript transition is going, and how it is structured. I was in a project that involved a team of mostly traditional enterprise .NET devs writing a greenfield app in Python (language choice mandated from up top). The result was basically something that was designed like a dogmatic enterprise .NET application, only using Python abused and wrangled to fit that style. After that project was done, for subsequent work, the team split into two camps - one camp that despised being forced to work with Python and continued to write Python in enterprise .NET style, and one camp that decided to explore more about Python and try working in more "Pythonic" style. Code review sessions were full of emotions and drama. Pretty much everyone in the first camp eventually left, either for other internal teams that were still working in .NET, or for other companies.
- dynamite-ready 6y ago
  Yes. This sounds a lot like my current experience, except for the language involved (TS in my case) and the team split (I'm the one with less .Net experience). I like to think I'm experienced enough to see it as a valuable opportunity to learn something that's not just about code and product... Anyway, everything else you mentioned sounds uncannily similar. Makes you wonder how such a culture develops. The only constant appears to be Microsoft development tools, curiously.