Hacker News Reader

Comment by lol768 | Hacker News Reader

> In fact, the reason I'm adverse to certain tech like .NET is also related to company type/culture that would use such tech, more so than the actual tech itself. I happen to like C#.

This is interesting to read - what does a .NET company type look like to you? (And follow-up, does that stereotype assume developing on Windows with .NET Framework; does it hold for .NET Core?)

View on HN

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) 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.

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 :)

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.

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...

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.

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.

Mostly of the "software/tech as an unrespected cost center" kind. Ties in with my other bit about "must wear business casual". Now I know not all companies using .NET are like that of course, but a huge majority do seem to be. Disclaimer: I started my career, and spent most of it, as a .NET dev.

Does anyone really use .NET Core in production? Maybe in certain locales and industries only? I've been on the job hunt for a while, talked to and interviewed at numerous companies, and I've yet to encounter a single company advertising that they use .NET Core.

I've been using .NET Core on prod for like 2 years

Friends from other companies are also using .NET Core whenever they can, so yea.

Eastern Europe here.

Stack Overflow uses NET Core. I think the reason you don't see it in the wild as much as is because NET Core is pretty new. Stack Overflow migrated in late 2018. That's really about when NET Core became mature enough to use in production for new development, never mind legacy. Most companies feel no pressure to use NET Core - their huge amount of legacy software still works and can be maintained on NET Framework. Not to mention Windows-based tech like WPF and WinForms only just got support with NET Core 3 which was released 7 months ago. Companies with 'unrespected cost centers' as noted are especially conservative.

Reply on news.ycombinator.com