Why you can't be a good .NET developer | Hacker News Reader

Why you can't be a good .NET developer

codeofrob.com

28 pointsgh-lfneu2820 comments

50% smug developer snobbery and 50% truth. As much as I hate to admit it, it is easy to be mediocre in the legacy webforms world of .NET and a lot of places are stuck in that world. To some degree that speaks to the success of ASP.NET allowing decent programmers to double as mediocre web developers. I was one for a long time and am still one some days.

I think the MVC, Entity Framework, Web Api world of .Net is as good or better than anything else out there and a 'good' developer in that world is just as accomplished as a 'good' developer in the Django or Rails world.

I would also argue that it has proven much more challenging to maintain and extend legacy .Net applications than it was to work on a clean, solid, and in many ways more complicated Django/Postres/Ubuntu stack. Keeping a beat up winforms,webforms,soap driven SOA legacy stack straight takes a decent amount of patience.

I'd add WCF to that list as well, especially when the client and server are both in .Net languages... I never really liked the XML binding, and preferred to use programmatic binding, and generally with JSON endpoints... but the ability to distribute a simple class library of interfaces, that could then build a WCF client instance and connect to a given endpoint is really nice. The painful thing to me was always consuming ill-defined services written in other languages.

I always hated webforms, to be honest, before MVC, I'd usually write as simple aspx as possible, and use ashx for most of the edges... The first couple releases of ASP.Net got better, but still the disconnected events were somewhat more painful than straight html+js when it came to anything complex, more so as ajax took hold. MVC made those edges easier to write. For the past 5 years or so, been writing far more node.js, and though less polished than .Net on the server, has been far more pleasant.

The problem with the OP is that it can be summed up as "writer doesn't want to work on legacy systems." Good for him! But the amount of greenfield development is a minuscule slice of SLOC out there in the world.

Context matters. I've seen "derpy enterprise shops" build lambda architectures on Azure, startups cargo-culting their way through MEAN-stack apps, and, yes, LoB apps that were still Java-through-CGI (shudder). You can be a great developer in virtually any language, in virtually any environment. Or, I suppose, you can bitch about it on your blog.

I can't work out whether this is a criticism of a corporate development culture (equally applicable to other tech stacks and legacy + reality of corporate world), or a "Microsoft is bad" argument, or possibly an ad hominem "only morons do MS, do you want to work with morons?" style argument...

Frankly I don't like the level of generalisation and apparent prejudice, and although I respect one's right to hold such an opinion, I think the conclusions of the article are wrong.

I think the first one, corporate development culture, is pretty much the correct one. The difference between .Net and other environments is the ratio of corporate to everything else is so skewed that you have to either "think enterprise" or jump ship for something else.

All that being said, I'm sure if you have a well run IT department, you can get along just great with .Net even at smaller companies.

I think he's leaning towards "good .NET devs leave the .NET world," but yea it is ranty. The same could be said for Java (there are a lot of better technologies based on the JVM, such as Scala. But the learning curve can be challenging).

> this is a criticism of a corporate development culture

I feel like a more though out post could have arrived in this camp. This isn't a .NET isolation issue (although you could argue the Windows eco-system is shit to develop on -- but that's another rant), but more of an issue with companies that can't quickly move to new technologies and software stacks due to a huge burden of technical debt, insufficient integration tests and, the most challenging, a team of mostly mediocre developers who are afraid to, or refuse to, try new things.

I'm currently working in a team on a MEAN-stack project... it's less than 6 months old, and feels like it was made 6+ years ago. I've met a lot of resistance in terms of getting Webpack and Babel introduced... I've never been a fan of ng's dependency injection system, it always felt like cjs's require (combined with browserify/webpack) is cleaner.

I know these tools are fairly new... that said, working without them feels like developing web applications back in the late 90's. Just painful.

I've interviewed for a few positions where Java is used on the backend, and because of my strong front end and JS experience the assumption is that I won't be able to keep up on the backend. It's pretty ridiculous, when the opposite assumptions never seem to present themselves. I've worked with multiple database systems, and multiple server-side architectures. Just avoided Java because every time I've used it, it just felt excessively painful to use.

I've said for the past few years (ever since Prototype, then jQuery) that one should be looking for solid developers with the ability to learn, try and adapt over someone with a checkbox skill. Yes, you'll be hard pressed to find a developer with "solid React experience." The point is that hiring a solid developer is hard, but that should be the primary goal.

>I know these tools are fairly new... that said, working without them feels like developing web applications back in the late 90's. Just painful

Large scale Javascript development is an absolute nightmare without TypeScript

If you're using feature based project structure, it really isn't bad. Typescript doesn't offer that much over modern JS development with webpack.

MEAN is actually pretty outdated. More like React and RethinkDB and a million other things.

But yeah, having had all three roles, back-end is often much easier than front-end or full-stack, despite the false sense of superiority that back-end only devs have.

Also having done C# for several years as well as JavaScript, Java/C# type languages are overall easier than JavaScript because you get things like intellisense, static type checking etc. from the compiler.

I agree on C# being easier overall, but I find less disconnect with node.js on the server when JS is the client. It's usually the structure of Java/C# type projects that tends to get to me more than anything... just more complicated than it should be.

I would suggest that good .NET developers (like any other language, etc.) are the ones that aren't constantly looking for a 'new technology' to move into, and instead get on with writing quality software / solving the problem at hand.

I'm not sure I entirely agree with that. A lot of times, people get stuck on a certain tooling, or patterns even when they don't apply. In particular with .Net, is the Data Application Blocks of Enterprise Library, and the rest of entlib in general.

Most of which only makes software more complicated than usually necessary, and makes me shudder to this day when I hear the term "Enterprise" applied to software. It isn't that it doesn't work, or that it never serves a purpose, but that most of the time it is applied it isn't good.

I spent the better part of the 2000's writing code in C#, it's still a favorite language. I've spend most of the past 5-6 years writing far more JS, and a lot of Node migration. Some of that isn't so great either. In the end, writing code that's easy to setup, configure, follow and understand is more important than any language specifics, and I feel that Java and C# developers forget that in favor of "Enterprise" practices.

I think that it's also common for teams to get painted into a corner trying to use the next great, bleeding edge, thing. I too shudder at the term "Enterprise", but I also shudder when I see a company desperately trying to hire a "NoSQL Expert" at any cost because they built everything around Mongo when a relational database would have been fine.

True enough, though I actually like mongo's document centric database for a lot of use cases. Though with MS-SQL 2016, Postgres + plv8 and binary-json, and rethinkdb, there are better options these days.

Derpy enterprise folks have had too many traumatic turns with Microsoft tooling. There is a reason for this apparent or perceived "stupidity". It isn't stupidity. It is caution.

The trauma really began with VB6, then ASP, then continued with Webforms, then Silverlight, then WPF ... if you thought that the current cohort of JS developers have framework fatigue, you should see surviving Microsoft "derpies" nursing technical debt such as LINQToSQL or strange extensions of Sharepoint.

The Java folks were less traumatized in this regard. But they had their moments with EJB (entity beans anybody)?

Yeah the community focuses more on the 9-5 line of business apps. It moves slower but for different reasons. Honestly I haven't looked back. I like being able to push the new boundaries

Where do you move? what kind of industry?

Industry does not matter because it is the "company" that picks the tools so you will want to find a company that is capable of change.

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.

Reply on news.ycombinator.com