
Why you can't be a good .NET developer - gh-lfneu28
http://codeofrob.com/entries/why-you-cant-be-a-good-.net-developer.html
======
lujim
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.

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

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

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

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

~~~
aphextron
>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

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

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

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

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

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

------
ak39
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)?

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

~~~
andymaster
Where do you move? what kind of industry?

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

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

