
A response to “Why you can't be a good .NET developer” (2016) - douche
https://ayende.com/blog/174433/re-why-you-cant-be-a-good-net-developer
======
dev360
From the original post:

> This is why you can't be a good .NET developer, sooner or later the
> frustration sets in and you go and do something better. The average ability
> and desire for something better just keeps on plummetting whilst Microsoft
> try to chase the brain drain by casting little nuggets of mediocrity at the
> people left behind scrabbling in the mud.

This was exactly my progression when working .NET in 'Derpy Enterprise Shops'.
I don't think it necessarily kept me from becoming a good .NET developer.. But
eventually I grew cynical and tired and just gave up on the entire stack. That
delta between what we were doing vs could be doing felt like it was too big.

In the end though, its absolutely about culture and Enterprise IT will
suffocate you no matter what language.

~~~
Delmania
I really can't echo this sentiment enough. You listen to Hanselminutes or .Net
Rocks, and you hear about all these great things people are doing. Did someone
build a cross-platform game using Xamarin Forms and Azure Service Fabric? That
sounds cool, sign me up! Then you walk into your day job, and it's building
yet another "textbox over database site" with ASP.NET 4.5.2 and Bootstrap.

Where can one find these .NET shops that strive to make use of the latest
developments?

~~~
freddref
I feel like there is not enough "interesting" work to go around. Maybe more
experimental work is seen as less likely to be profitable or too risky to
implement?

~~~
douche
I wonder sometimes if, in the quest to make things "interesting" again, we
fall into the trap of making the uninteresting things so damned complicated
that we find that scut work foisted back on us, because the tooling has become
to complex.

As I survey the mess of JS and transpilers and server-side technologies that
have amassed themselves before me, to do the same thing that a Visual Basic
Forms app could do 20 years ago, sometime I weep and gnash my teeth a little
bit.

~~~
freddref
Agreed, we may be doing interesting work horizontally, reimplementing things
that have already been solved. (Maybe this is natural in the evolution of
things, searching for a breakthrough.)

------
dep_b
The problem is Enterprise not .Net. I have the freedom to pick whatever
technology I please as long as I deliver a product that works within the
specifications of my customers and I find there is a place for for example
ASP.Net MVC API's written in C# or Windows services written in F# even when
given a complete free choice.

Sometimes I pick PHP as "must run anywhere" is the requirement. The next day
I'll pick Swift or Objective-C because it's something Apple related. But .Net
is always a possibility.

But yet while nobody really _forces_ me to use a .Net stack I still pick it
since the stack is really stable and relatively easy to use (compared to the
perpetual change and chaos of a Modern Web Stack for example). Something I've
written 4 years ago will still run and compile like yesterday even if I've
abandoned it in the mean while.

I've been in those soulless Enterprise shops and it's just what happens to
places where people go everyday to watch the clock go six about 28 times per
month so they'll see the number on their bank account grow with a predictable
number every time.

But somewhere in the world these places exist full of PHP developers or Java
developers. The thing with Java or .Net is that some customers have really old
stacks and don't want to change anything. It's the new Cobol for some
companies while other companies do really cool cross-platform stuff. It can be
both. Take care where you take your resumé since the cool jobs are much harder
to find since nobody with a living soul wants that kind of enterprise jobs.

~~~
c0achmcguirk
You made the point I wanted to make. The problem is Enterprise, not a
framework.

I'll admit--the Microsoft stack is a walled garden. It offers some nice
features like Visual Studio integrating with Visual Studio Team Services with
its own issue tracker and build server and so on. If Microsoft supports your
workflow or integrates with the tooling you like, awesome. If not, well, just
wait and hope that it will someday support what you're looking for.

 _That_ is the frustrating part of the Microsoft stack. It can be overcome
with some architecture decisions at the outset of the project. You don't have
to stay in the walled garden.

But the Enterprise is where innovation dies. The Enterprise is where motivated
developers' souls are sucked out as they are told "no" constantly.

.NET isn't the problem.

~~~
lmm
But .net is inherently enterprisey. You have to license all the things you're
using, or did until recently - Visual Studio, SQL Server... you may not have
to pay if you're a small business or whatever but it's always going to be a
lot more effort than just clicking download. That has a chilling effect on
people using these technologies for the side projects that become productive
small businesses, and it compounds because if no-one's using that stack in
these places then there's no open-source library ecosystem because there's no-
one to create that.

~~~
cwbrandsma
No different than the Java shops I've seen.

~~~
lmm
Very different in my experience; there's a lot more on maven central, because
the toolchain and other popular components (e.g. mariadb) are freely
available, so you can very easily spin up the same environment at home.

------
bartread
I find it bizarre that the problems of enterprise software development are
being blamed on a technology stack. _Any_ technology stack.

I'm primarily a small company kind of guy but I've done a couple of big
enterprise gigs now. Currently I'm working for a large multi-national retailer
and... well, it doesn't bring me a lot of joy. And why is that? Well, not
because we're using .NET, although we are, and not because I'm surrounded by
"derpy enterprise developers", because I'm not. In fact, I'd go so far as to
suggest I'm in a derp free zone, yet it's still hard to get anything
productive done.

Why is that? Well, here are a few issues:

\- Culture,

\- Politics and egos,

\- Legacy - just tons and tons of legacy,

\- Complex business requirements, often poorly or incompletely understood by
everyone involved,

\- Distributed teams,

\- Sheer weight of numbers in terms of people and projects (remember Fred
Brooks),

\- Meetings, meetings, meetings,

\- BAU,

\- I could go on.

The current choice of technology stack doesn't even factor into the equation.

Legacy itself is a complex issue that goes way beyond technological concerns
and can cut right through to how the business makes money at a fundamental
level.

~~~
robashton2
I find it bizarre that the original blog entry was seen to be blaming the
technology, quite the inverse in fact.

------
Niksko
I assumed that .NET shops sucked, as did a lot of my peers at university. Then
I started working at one, and found that C# is a nice language, Visual Studio
+ Resharper is a joy, and that if you follow sensible architectural patterns
you can write clean and elegant code.

Everything sucks if you do it badly.

~~~
eropple
C# is a great language. I should think so--I've been writing it for twelve
years, I don't write C# professionally but I pay for ReSharper, and I used to
be a _huge_ Mono booster back-in-the-day. I even did Google Summer of Code for
them and made friends I've kept ever since. But whole I've consulted for .NET
shops, I've very deliberately avoided working for them for a lot of the
reasons described in the article to which this one replies.

It's not .NET. It's the mentality of so very many of the shops that _pick_
.NET. The stack and the tooling and the nigh-inevitable process pile-on apply
what I feel is more or less a band-pass filter on your output. It's relatively
hard to write really stinky code. But it's also relatively hard to write great
code. That's not a C# thing--you can write great, brilliant, interesting,
smart C#! But doing so at a ".NET shop" strikes me as profoundly unlikely. I
have yet to see one, parts of Microsoft aside, that seems to actively reward
being smart and curious and expansive in your skill set--and I think a lot of
it is because you're a .NET shop, the batteries are included, stay in your
lane.

(The same criticisms apply to Java-not-Kotlin-or-Scala shops; fair is fair.)

~~~
wvenable
> But it's also relatively hard to write great code.

What's the definition of great code? In all the languages and platforms that I
know (C, C++, JavaScript, Python, Java, PHP, C#, etc) if someone wanted me to
write "great code" without any other qualifiers I'd pick C# for the job. It's
just such a nice well designed static language (except for nullable
references) with a reasonably well designed framework that producing great
code is pretty easy.

I'm patiently waiting for Microsoft to get .NET on everything but for now it
seems like JavaScript is the king of that goal.

------
smt88
I'm using C#/.NET 4.5.2 for the first time at a small startup. The original
architect came from a bank. He's a fantastic programmer and he organized the
code in a logical, easy-to-maintain way.

Still, we spend about 30% of our working time (30%!) fighting the tooling.
Visual Studio 2015 is a buggy mess, and 2017 wouldn't even build our projects.
Everything happens at a snail's pace and is incredibly complicated.

The error messages are opaque to the point of making me laugh out loud at
times, and doing even tiny things (like changing the status code of the
response in the API) is complicated and hidden away under many layers of
magic.

Don't even get me started on Entity Framework. What a fucking disaster. When
it works, it's amazing! When it doesn't work (or when you need to do something
simple, like _update a row_ ) it becomes a black swamp of meaningless error
messages and trial-and-error frustration. Our most experienced engineers have
been working with .NET and EF for many years and _still_ couldn't figure out
how to do an update (in one particular case). The solution? Write a raw SQL
query with a "TODO: use EF" comment added. Time lost? TEN hours. I'm not even
kidding.

Maybe people who like .NET have never had a better experience, but I can
assure you that even with great engineers at a small shop, it is not even
close to the best experience. Comparisons to Java are accurate.

~~~
paulirwin
For anyone that might not be familiar, Entity Framework is an ORM (object-
relational mapper). The "blessed" way of doing an update is to retrieve an
object from your context, change its properties, and call SaveChanges on the
context. Yes, this can be terribly inefficient, particularly if you're trying
to update many rows at once. But it works okay for single-row updates in a
CRUD app at the expense of having to run the SELECT first plus all the
reflection and change tracking.

If you want to do fast, single-call updates without first doing a SELECT, or
updates on just a few of the row's columns, since that can't easily be done
with tracked objects, you're swimming upstream against what ORMs are designed
to do and so your best option is to get out of ORM land and do a SQL query.
Using context.Database.SqlQuery() or another library for these purposes like
Dapper to parameterize your queries via reflection could help here.

~~~
Flott
_IF_ you have the primary key of the entity that you want to update, EF allow
you to attach it to the context without querying the database. After attaching
it to the context, you can set the new values, mark them as modified and
(finally!) call SaveChanges.

\---

I do agree with you though! Dealing with it's limitations and edge case mean,
sooner or later, falling back to SQL.

EF is (imho) very hard to master and very easy to use "badly".

------
UK-AL
"Tangible examples? I remember well the insistence of one boss that we use TFS
because some developers would find it hard to use git. I remember the
steadfast committal to ASP.NET web forms because the "new concepts" in ASP.NET
MVC were going to take too long for the team to become productive in."

I've gotten this on EVERY stack. Not just .net.

I thinks it's more do with age of the project your working on. There is tons
critical business applications in .net and java and they don't want to break
anything and prefer stability.

If your developing something new, the technology is up for grabs.

~~~
NoGravitas
Yeah, it's definitely a culture problem, not a platform problem.

~~~
moomin
The culture that leads to Cobol programs running banks with expiring
developers.

~~~
juliangoldsmith
How exactly would you rewrite a 10M-line codebase in a new language, without
any sort of bugs?

More importantly, how would you convince management to allow you to do so?

~~~
moomin
That's the whole point: you shouldn't get into this situation in the first
place, and the reason you did is that you've got a culture of short-termism
that doesn't place enough weight on maintainability. This disaster's been 40
years in the making, and everyone thinks they made the right call.

I have exactly zero solutions to this. If I did I would be rich beyond the
dreams of Bezos. But let's not pretend that this isn't the end game of a
short-term, low investment, low innovation culture.

~~~
juliangoldsmith
A culture of short-termism isn't the problem here. The problem is that the
business rules that the code needs to implement are ridiculously complex.

Keep in mind that the sort of organizations that use large Cobol systems (e.g.
banks) are typically subject to very large amounts of regulation. Their code
has to meet all the relevant regulations at all times, plus handle internal
business rules.

The laws for all of the regions a large bank works in would likely be tens or
hundreds of thousands of pages. There isn't a way to condense that into a
small amount of elegant code.

~~~
moomin
Well, it pretty much is. Everyone's concerned with how many eggs they're
dealing with. But the basket's falling apart. It's not like we haven't already
had situations where banks have found themselves completely unable to process
payments for weeks at a time. And it's only going to get worse.

------
JamesBarney
Having worked at an enterprise company that used Go, Node, and Scala, let me
tell you .Net isn't the problem.

The .Net stack is wonderful. The tooling is fantastic. The base libraries are
robust, well documented, and broad. And most projects are pretty consistent.

And when the enterprise abandoned this for less mature stacks they magnified
all of these typical enterprise problems. Because simply trying to debug
poorly written C# is orders of magnitude easier than poorly written
JavaScript.

------
sharemywin
I'm not sure why there's such a harsh reaction to "developers that just want a
job." I used to enjoy programming. I still enjoy learning new things. I have a
life outside of work. Why isn't 23.8% of my life not good enough?

------
msimpson
Rob Ashton on .NET: "you're working on a platform that is primarily used by
derpy enterprise shops, you will continually be held back because those derpy
enteprise shops are continually be held back by the derpy enterprise
developers that work in the derpy enterprise shops."

Can we just ignore this guy now?

~~~
moomin
The irony being, Oren clearly doesn't ignore Rob, since he's paid him a fair
bit to work on Raven over the years.

~~~
romanovcode
Yeah, I also like how he bashed C# because he used inheritence in Raven and
now has problems.

Like you can't do composition in C#. You can't blame language for your shitty
design!

------
gjmacd
It's not C# (as a language), which is benign and a good actor in the set, it's
the stack. Ever try running a Windows / IIS and SQL Server stack in the cloud
-- do it only if you want to lose sleep nights and spend weekends away from
the family. The language is fine... Let's hope the move to Core and Linux will
take the language and the .NET technology to a better platform, but right now?
It's a disaster as a robust Cloud platform.

Windows and IIS is simply a BAD, BAD, BAD server technology as a whole. It's
ill-equipped to to be robust and fault tolerant. Its simply the weak part of
that .NET narrative, no way around it right now...

~~~
Illniyar
Just tried it a few months ago, deploying a new project to Azure.

Best experience I've had deploying to the cloud - maybe 10 minutes of work,
mostly getting acquainted with azure cloud.

Beats Heroku's plugin/cli/github flow and AWS' configure 50 tools process
hands down.

It really only works with .net, visual studio and sqlserver. But really that
is what you want if you are a .net developer.

~~~
gjmacd
Azure is built for Windows, I hope it works well. However, I'm sorry...
there's no way you're going to convince me of Windows as a "stack" is more
reliable and robust, or even as scalable (in concurrent users and cost) than
another stack like GoLang, Node, Python, Elixir... nope. Not going to agree
with that man, I've been around much too long to see bullshit issues with
Windows/IIS take town a whole operation based on SIMPLE issues -- hell IIS
alone is a reason not to choose Microsoft as a stack, it's a DOG WITH FLEAS.

------
pawadu
I worked about a year writing desktop software in C#. Probably the most fun
period of my carrier, we were getting things done and delivering before
schedule while all having a great time.

Also, I get this feeling that the original poster (Rob) is the kind of guy who
has zero experience outside a few web frameworks. The kind of guy that barely
even knows that desktop, server and embedded exist.

~~~
icebraining
_Also, I get this feeling that the original poster (Rob) is the kind of guy
who has zero experience outside a few web frameworks. The kind of guy that
barely even knows that desktop, server and embedded exist._

I think these kinds of disparaging remarks about people don't belong in a
civil discussion. If you feel that the opinion isn't worth being discussed,
you can just not comment.

~~~
pawadu
No, I don't feel this was a disparaging remark about a person.

A guy makes a huge claim based on his very limited view of the market (while
insulting everybody). I think I am in my full right to call him out.

~~~
lobut
It's not about your "full right". It's about whether or not it leads to civil
discussion.

The biggest problem with discourse is that we think we know what the other
person is thinking.

~~~
pawadu
Fair enough, I will try to remember that next time.

------
icebraining
Blogger 1 makes overreaching claim when talking about a general trend. Blogger
2 focuses on the overreaching claim and mostly ignores the overall point.

Sigh. This kind of arguments is way too common.

~~~
majewsky
> Blogger 1 makes overreaching claim when talking about a general trend.
> Blogger 2 focuses on the overreaching claim and mostly ignores the overall
> point. Commenter uses the opportunity to express his superiority above both
> sides.

FTFY

~~~
mikekchar
Stack overflow.

At least it is tail recursion, though.

~~~
majewsky
I actually expected someone else to do another FTFY by adding "Second
commenter takes discussion to the meta level."

~~~
teddyh
Last comment in thread compares HN to Reddit.

------
robodale
I've switched to node platform in the last year, but I've done .NET since
2002. I can still build a solid site in wayyyyy less time in .NET/C# than in
node. I still think .NET MVC web apps are a modern marvel. I have yet to
do/see anything on the node platform that comes close.

~~~
dagw
Can you point to a good intro to .NET/C# web dev guide. Basically how to go
from zero to a minimal REST API that can talk to a database in a modern way.
Ideally something that that doesn't assume IIS (or even windows)

~~~
kirse
[https://docs.microsoft.com/en-
us/aspnet/core/tutorials/web-a...](https://docs.microsoft.com/en-
us/aspnet/core/tutorials/web-api-vsc)

------
nikon
Rob is not wrong in my experience. Contracting in London doing .NET stuff
means 9 times out of 10 you're at some enterprise place with stupid rules and
processes that ultimately make it less fun than it should be and you end up
hating them for it.

Nothing to do with the language/framework, but its adopters.

------
rb808
I love C#, .Net for server side work. My old project was C# servers on Windows
Servers and it worked great. I much prefer to C# to Java & Python which is
what I do now, I'd even go so far to say as our Windows Blades were more
reliable and easier to maintain than our current Linux ones.

The biggest problem with .NET and why I switched is that Linux is free and now
has biggest mindshare. Most free and opensource products really are Linux
first platforms.

It used to be that you couldn't get fired for choosing Microsoft, but its
flipped that free software is so good you feel silly paying for commercial
products like Windows.

I can't see much future for the Windows platform which is why I changed. So I
think the headline is wrong - any good developer can be happy in C# and write
great .net apps - so the good .NET developer does exist. But its also kinda
true because the balance has shifted and great new applications are now on new
platforms.

~~~
pawadu
Isn't .NET Core a viable option on Linux these days?

~~~
oblio
It's getting there. It should be production ready this autumn.

------
alistproducer2
The original article is really a diatribe on enterprise shops disguised as a
critique of .NET. Anyone who has ever worked in a large, enterprise company
knows that it's all about warm bodies in seats. The environment selects for
people that want stability and runs off ambitious people who want to do "cool"
things. .NET is actually a pretty good framework for building apps and is
certainly no worse than J2EE or stack du joir for building SPAs.

------
nedsma
I'll refer to patio11's legendary blog post [1] (Don't call yourself a
programmer) by saying don't be just a .NET developer. C# is a great language,
but you know, so are Python, Swift, Go, Elixir to name a few, and are even
easier to learn/practice. By staying exclusively committed to a single
language/framework, you're missing out on a lot of fun. The initial
productivity anxiety usually wears off after a couple weeks.

[1] [http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-
pro...](http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/)

~~~
pjmlp
Knowing the language grammar and semantics is one thing.

Knowing the language grammar and semantics, standard library, good quality
third party libraries, database drivers, official build tools, IDE and
VIM/Emacs plugins, best practices, main blogs,tooling for native applications,
tooling for web applications, backend servers, .... is another matter
altogether.

Now multiply this per each language.

I rather constrain myself to JVM/.NET stacks, with a little C++ on the side
for pure native stuff. That is already a lot to keep on my head.

Everything else is nice to dabble on rainy weekends, but that is about it.

~~~
tonyarkles
I'm curious, as a long time emacs lover now doing C# work in a day job... is
there a good way to do C# in emacs? I'm quite happy with VS2015+ReSharper, but
I do sometimes long for emacs.

~~~
pjmlp
Being an IDE person, I never bothered searching for C# on Emacs.

I am an Emacs person regarding Emacs vs VI debate, and got to learn how to use
it quite well back in the day (actually XEmacs), but it was only as a
workaround for lack of nice IDEs in UNIX.

Nowadays I seldom use it.

EDIT: I guess Omnisharp plugs into Emacs as well.

------
yks
When Paul Graham writes about Lisp as a "secret weapon" I often wonder that
.NET is that "secret weapon".

C# is absolutely powerful and the ecosystem is such that you can actually work
on your startup and not on fixing a web of broken NPM packages. Admittedly
this doesn't give you GitHub "points", but hey, there is .NET Core for that
now, usually as broken as JS stack and just about as fun if getting bogged
down in months old but already deprecated functions is your kind of fun.

.NET makes a ton of sense to use for a startup but that's the space where it
is severely underused mostly for fashion reasons (and because it doesn't run
on MacBooks).

------
NoGravitas
It's a culture problem, not a platform problem, and the problem isn't with
.NET shops per se, but with enterprise shops that [treat programmers as
fungible cogs][0]. Language enters into that _to some extent_ , because this
kind of shop wants programmers with a certain baseline of skill in a widely
used language with a widely used stack, and Java and .NET fit the bill. But
there's no reason you can't do interesting stuff with good methodology in
those languages...if you're not trying to do it at one of those shops.

[0]: [http://www.loper-os.org/?p=69](http://www.loper-os.org/?p=69)

------
psyc
Person 1: Because a lot of .NET teams are like...

Person 2: Wrong! Because not all .NET teams are like that.

~~~
egeozcan
The problem is the generalization over the stack instead of the type of
company.

~~~
psyc
Agreed. I'm not aware of any language/stack you can't be a great dev in. Slash
has said that although he has favorite guitars, he believes a good guitarist
can grab any cheap guitar out of a crate and make it sound amazing. Or, it's a
poor craftsperson who blames the tool.

Now, it just so happens that as general frameworks go, IMO C#/.NET _is_ the
signature Les Paul.

~~~
dev360
Oh no you did not just go there... :) I thought Java was the one everybody
tried to copy :)

------
martamoreno
Why would anyone even bother to respond to a statement "Why you can't be a
good .NET developer."? A person saying this is obviously deranged. And why is
it worth having this on hacker news? Someone seems to be boosting this blog
lately. Another useless blogpost on top of hacker news.

------
AngeloAnolin
Progressing to become a good developer, I believe requires for one to go
through some StackOverflow questions and postings. Oh, tell those who say that
you cannot be a good .NET developer that StackOverflow is built on the .NET
platform. <><

------
lmm
> Looking at the kind of directions that people leave .NET for, it
> traditionally have been to the green green hills of Rails, then it was
> Node.JS, not I think it is Elixir, although I’m not really paying attention.
> That means that in the time a .NET developer (assuming that they investing
> in themselves and continuously learning) invested in their platform, learned
> a lot on how to make it work properly, the person who left for greener
> pastures has had to learn multiple new frameworks and platforms. If you
> think that this doesn’t have an impact on productivity, you are kidding
> yourself.

Vigorously asserted, but I'm guessing with zero evidence? I would certainly
expect a productivity difference between someone who stayed in .NET and
someone who left and learned something different, but my assumption (and it's
nothing more than that) is that it would go in the opposite direction to what
the author seems to assume.

~~~
Delmania
Wide versus deep. The person who focused solely on .NET would be the expert
that you'd want to look at a set of requirements and determine if .NET is the
appropriate platform and then what technologies would be the best to utilize.
The latter would be a person you'd want to lead the development efforts. His
exposure to different paradigms would be helpful in writing efficient code,
someone who can consult the expert on how to do the best practices in the
technology.

------
vuyani
The original author missed a vital viewpoint. He assumed that .net developers
would never be good because they reluctant to try new technologies. He then
evaluates that as a bad thing. Thats not quite so. This is a testament to how
good and mature Microsofts ecosystem is, and the benefits thereof. In business
sense. It doesn't make sense to hire a pool of developers who are good at
various cutting edge technologies when the current stack can cater for all
business needs. Most .net shops are enterprises which have no need for cutting
edge technology. In my opinion,that conclusion should then lead to, should we
rather not ask "what makes a good developer?". Theres no simple answer.
Example, to a business that employees you to ship code, and you constantly
maintain good quality and meeting deliverables. Would that not be considered a
good developer?

------
_pmf_
It should be below everyone to even respond to this anecdotal crap (the
original article, not this response!). I dislike a lot of the ridiculous yak
shaving that JS developers of large corporations try to push to the community,
but I would never claim that this in any way affects each developer in the
community.

> It'll not happen because as long as you're working on a platform that is
> primarily used by derpy enterprise shops, you will continually be held back
> because those derpy enteprise shops are continually be held back by the
> derpy enterprise developers that work in the derpy enterprise shops.

Some people have real business problems to solve instead of rewriting their
complete stack every half year, for fuck's sake!

~~~
nsxwolf
Personally I enjoy knowing my paycheck comes from the sale of products and not
ad revenue or investors.

------
atemerev
A counterexample to the original post: Java. It is also all about stability
and backwards compatibility, and now owned by Oracle (which is an epitome of
enterprisey derpiness), but Java platform still somehow retains its vibrant,
innovative community. One might say that Scala and perhaps Clojure are the
main innovation drivers, but .NET has F#, which is no less innovative.

So, I think it must be something else. Perhaps their years of focus on Windows
platform, which is preferred in enterprisey sweatshops, not in the latte-
drinking hipster SV community.

------
anton_gogolev
Real artists ship
([http://wiki.c2.com/?RealArtistsShip](http://wiki.c2.com/?RealArtistsShip)),
and the frowned-upon enterprise .NET developers ship shit. Yes, the code may
be disgusting, none of HTML5, CSS3 or Babel were used in a corporate portal,
but. They. Ship. Shit. And this alon makes them good programmers.

~~~
guitarbill
Yeah, let's ship some rubbish and let the next guy fix the mess, because by
the time it needs maintaining or majorly expanding we'll be long gone. Good
job everybody! /s

~~~
anton_gogolev
Or else we can hand-craft our next isomorphic Node.js/Angular 7/React Redux
Native Embedded SPA - of course "with all the <3 in the world" \- and in two
months (just when we return from the latest and greatest meetupy conference)
find out that one third of the dependencies went missing, one third got non-
backwards-compatible changes, and the remaining ones were rewritten from the
ground up just for the hell of it. And shit does not even start up properly,
90% of the unit tests fail unexplicably and no one wants to touch the codebase
with a ten foot pole.

------
mannykannot
The article being replied to made a common error: attributing a property of
the human environment to the technical one instead. It is in the same category
of error as thinking that a change in platform or programming language will
solve all your problems.

------
elorant
The problem with .NET is that C# is evolving too damn fast. So no matter what
you build you can't avoid the feeling of been left behind by progress. I'm
still using C# 4.0 for my projects. I can't be bothered to follow every little
shinny thing MS decides to publish, or update VS every couple of years. I have
shit to build. And one reason I don't bother following the trend is because MS
has the tendency of abandoning technologies all too often. Anyone remembers
Silverlight? Or how many rendering engines did they change in ASP.NET MVC.

~~~
UK-AL
Compared to the technologies people learn today, .net is a glacier.

------
partycoder
.NET technologically isn't bad.

What is sort of inconvenient is the dependency management, and that has as a
consequence many .NET shops reinventing the wheel.

Another bad thing is the presence of closed source proprietary libraries,
meaning they can't be forked and adapted/improved upon. This has somehow
changed lately with Microsoft open sourcing some stuff.

~~~
tonyedgecombe
Dependency management is bad on most platforms, it doesn't seem to be a solved
problem yet.

~~~
partycoder
I am not so sure about that.

Dependency management in .NET is not as good as let's say, Java, Python, Ruby,
node.js.

Setting up your project to use Maven, pip, gems or npm respectively is very
easy. I have tried nuget, but it is not as nearly as easy to use or reason
about as other systems.

~~~
mattmanser
What exactly is wrong with NuGet? It's very simple, I think you just didn't
give it a chance

For example a month ago Facebook broke .net's built in social login, all
installed with NuGet, so I ran a single command and it was fixed.

If you're talking about front end, NuGet can handle it, or the recent versions
of VS have a built in task runner that you can easily setup to run Gulp,
Grunt, Yarn, Bower, whatever, if you so desire on build/debug/etc.

There are things to hate about the .Net ecosystem (TFS, I'm looking at you),
but NuGet ain't one of them.

~~~
partycoder
So far what I have seen with .NET project files is that: people modify them,
VS generates code into those files, and they contain a lot of stuff. As a
result, they're very painful to manage when trying to troubleshoot issues.
Then, because the project files get modified all the time it's a constant
source of conflicts in version control.

~~~
ygra
If project files get modified all the time then either you're constantly
moving, adding, or removing files from the project, or constantly changing
configurations and build settings. Neither should really happen _constantly_.

------
faragon
TL;DR: ad hominem arguments.

------
sharemywin
The biggest problem I see is if you don't like to wield your knowledge over
others and act like your way of doing things is the "greatest" way ever like a
Nerdy Donald Trumps, non-techies don't take you seriously.

------
mack73
A strong dev team will shine on any platform and in any language. A weak dev
team, given the right tools, can at least be productive. Which is why business
people who build business and need devs often settle on .net. Microsoft
learned long ago how to cater for the needs of these weak teams.

Are there lots of weak tems on .net? Sure, I would argue that is true.

> you can't be a good .NET developer

Really? That is Rob's conslusion? That's laughable. The best programmers I
know are extremely strong .net developers. I'm no Jon Skeet but I personaly
view myself as a 7-8 (out of ten) irregardless of platform.

If you identify with the platform you're on you are doing it wrong.

