A response to “Why you can't be a good .NET developer” (2016)

https://ayende.com/blog/174433/re-why-you-cant-be-a-good-net-developer

by douche • 9 years ago

116 194 9 years ago

pawadu5• 9 years ago

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.

icebraining3• 9 years ago

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.

pawadu5• 9 years ago

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.

custos2• 9 years ago

I feel people who generalize others with a certain specialty negatively is a kind of disparaging remark that doesn't belong in civil dicussion, so let's not pretend this is one.

The original blog is spewing some pretty stereotypical bullshit you'd expect from some teenager seriously engaged in a which OS or text editor is better holy war.

rhapsodic2• 9 years ago

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.

I don't think the comments were all that unreasonable considering that their subject (Rob Ashton) said:

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

psyc2• 9 years ago

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

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

egeozcan• 9 years ago

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

psyc2• 9 years ago

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.

icebraining3• 9 years ago

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.

majewsky2• 9 years ago

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• 9 years ago

Stack overflow.

At least it is tail recursion, though.

UK-AL2• 9 years ago

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

NoGravitas2• 9 years ago

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

Deinos• 9 years ago

Agreed. The type of culture that gives us classes like "AbstractSingletonProxyFactoryBean", etc.

moomin4• 9 years ago

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

lmm3• 9 years ago

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.

Delmania2• 9 years ago

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.

dev3608• 9 years ago

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.

Delmania2• 9 years ago

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?

dev3608• 9 years ago

Id try to look for a place to work that is more product oriented. I went another route and worked a lot with startups, but then you wont really find .NET very much.

manigandham• 9 years ago

There are several, follow the open source projects and developers and see what companies are using those and getting involved.

We're a marketing startup that uses the .NET stack and it's been a key driver in building a better product faster.

senorjazz• 9 years ago

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.

How is that any different to 99% of startups who preach they are "changing the world", but at the base of it, are just a crud app. Only difference is they are using a "hip" language which will probably make your life more difficult than .net

sotojuan• 9 years ago

You could use this template to complain about almost any programming job, not just .NET jobs.

donquichotte• 9 years ago

To be fair, I have tried to use Xamarin every half a year for the course of the past 2.5 years and have never succeeded in compiling even the most basic Android examples.

freddref2• 9 years ago

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?

alistairSH• 9 years ago

Same can be said of any number of shops doing the same thing with Java or php. It's not a the language or framework, it's the work. It just so happens that the types of companies that require "yet another textbox over database site" like to use established, stable frameworks.

TheRealDunkirk2• 9 years ago

You listen to Hanselminutes or .Net Rocks, and you hear about all these great things people are doing.

My problem with these kinds of Microsoft technology evangelism articles/videos is that it always seems like Microsoft has juuuust gotten their new hotness to work, and is telling the world that it's awesome, and ready for production. Then you go to implement it, and as soon as you leave the perfect world of their demo, it all falls apart, and THEN you find out the docs were written for the beta version, and no longer apply, so you're left guessing at the right invocation signature for the method you need.

My most-recent example of this was their Ruby bindings for Azure blob storage. I wasted DAYS fiddling with the docs, which showed MANY different ways to call the functions, none of which worked for me. I eventually had to have a discussion with one of the people linked to the documentation to get it to work. This sort of thing -- announcing new stuff that isn't ready for prime time -- has happened before (I'm looking at you, EF and WSL), and I expect it will continue to happen, because MS is usually playing catchup with other market hotness.

I haven't used them, but I have no problem assuming that, if I were to go startup a project with the bleeding edge of, say, Erlang, or Node.js, I could find enough documentation to get a working prototype up and running without a lot of hassle.

I guess it goes both ways, though. Once you muscle through Microsoft's bleeding edge, it really feels like you've accomplished something. My Rails app is sending messages, with JSON payloads, to an Azure blob queue, which is getting picked up by my internal Windows service, to be batch processed by a legacy command-line tool, and I'm having the time of my (development) life.

jasonkostempski• 9 years ago

If a .NET shop has any experience, they'll not be jumping on any MS bandwagons, it's a very risky business decision, especially if they're just making data entry software.

mustacheemperor• 9 years ago

I currently work as a .NET developer building for the Microsoft Hololens and it does feel like I might be the lucky exception. For the most part I avoid ASP etc and Microsoft redesigned a lot of the framework for UWP - it's pretty awesome to be able to write applications that build and run on a Windows computer as components of a hololens application and not need to change anything to integrate the pieces together.

I think the difference is that we use .NET because "it's the right tool for the job," to quote others in the thread. Effectively, it's the only tool for Windows MR development right now. I'd be way more miserable if I was forced to be building bootstrap sites in ASP because middle management said to use it.

Retric4• 9 years ago

Great developers avoid the beading edge, which let's them get stuff done. They don't give talks or write blog posts, because they are getting stuff done. So, yea you don't hear about them just what they did, because they are getting stuff done.

They also tend to have lives outside of work, because they get stuff done and go on to other things. Most importantly, they avoid the long drawn out design arguments because that's mostly just bike shedding and they have stuff to do.

btschaegg• 9 years ago

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.

Hm. I'm not sure that effect really depends much on the technology used. Sure, it's a factor and tools that make you feel like they are slowing you down can suck out much of the joy of building things.

But on the other hand: Isn't the true problem that you are building yet another "textbox over database site"? And you'll have to maintain it. This is the part that sounds much less exciting to me than the tech.

mariusmg• 9 years ago

about culture and Enterprise IT will suffocate you no matter what language

Bingo, no matter which language is , bad culture will still suffocate you. Nothing to do with specific programming language / environment.

FLUX-YOU2• 9 years ago

The rewards of being a good developer are too low anyway unless it's an impulse that you simply must satisfy for yourself. You'll likely just end up putting another couple of zeroes on someone else's wealth while they give you a fraction of that. I'd find something more worthwhile in life to struggle for.

dev3608• 9 years ago

Getting older, I can see the draw though.

Good pay, good benefits, easy work. Something to be said about that.

I'd just have to numb myself with opiates or something in order to stay calm, non-confrontational and mediocre.

kzisme6• 9 years ago

What would you consider a good developer? (technical skill vs adding business value)

I'm constantly curious about what other people are working on, or if they are re-writing the same CRUD app over and over.

pjmlp7• 9 years ago

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

This is the main issue, I have been seeing this since enterprise applications were written xBase, Turbo Pascal and C.

In the Enterprise, politics and developers being used as cogs trumps any kind of technology stack one can think of.

Loic• 9 years ago

I cannot upvote you enough.

From my personal experience producing "enterprise" code for the past 20 years with languages starting at Fortran and ending up with VB.net with all the Python/C/C++/Visual C++/Delphi etc. in the middle, the language/stack choice is orthogonal to the quality of the code base.

You can find wonderful code in VB.net and pure crap in Ruby and vice-versa. This is the company/coder culture which influences the most the end result. Blaming the tools in this case is for me the mark of a lack of experience both in programming and long term software development.

kzisme6• 9 years ago

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

The one thing I really worry about is being stuck in the MS stack for years and not learning as much as I can (or want to).

I still ~really~ dislike the term "IT" or "IT Dept" - since the majority of the time you are seen as some guy who works on computers or can fix your problem.

I just don't want to become stuck.

quantumhobbit• 9 years ago

It is all about making developers cogs. The language and frameworks are only useful so far as they make you more replaceable. Don't ever do anything clever or advanced even if it makes the company a ton of money or boosts productivity. Because the next cheap grad they hire to replace you might not be able to figure it out seeing as he only knows Java or .net.

At my job, they have started trying to convince us that "fungibility" is something that we should aspire to. As though we can't see what that means.

I'm not against good documentation and clean code that makes it easier on the next developer, but this is taking things to an extreme.

Niksko• 9 years ago

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.

sddfd• 9 years ago

QFT: Everything sucks if you do it badly.

eropple• 9 years ago

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

wvenable6• 9 years ago

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.

partycoder3• 9 years ago

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

tonyedgecombe2• 9 years ago

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

partycoder3• 9 years ago

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.

pawadu5• 9 years ago

What do you think of dependency management in .Net Core?

msimpson• 9 years ago

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?

moomin4• 9 years ago

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• 9 years ago

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!

anton_gogolev2• 9 years ago

Real artists ship (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.

dredmorbius• 9 years ago

Real artists also improve.

Toilets ship. Wouldn't want to make me eat what comes out, no matter how much it's ... shipped.

guitarbill3• 9 years ago

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_gogolev2• 9 years ago

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.

dep_b2• 9 years ago

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.

nxc182• 9 years ago

This is a really great point. I have 'old' web apps in .Net from a few years ago that just work today; same with old desktop code.

Go back to a e.g. Meteor app from a year ago and it will very likely be broken, either by some change to the client js runtime or some change with a newer version of node breaking packages. Unfortunately the changes to the client and security issues tend to force node+package updates.

There's a lot of underappreciated value in long term stability

pc86• 9 years ago

Unfortunately the changes to the client and security issues tend to force node+package updates.

Are you sure that shouldn't be "fortunately?" I write 90% C# and 10% JS and I would be so happy if there was some structural reason requiring .NET apps to be updated regularly. The number of apps I've run into that are several years past EOL but the client refuses to update them because "well it works and we haven't been hacked yet" is indeed soul crushing after a while.

c0achmcguirk• 9 years ago

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.

lmm3• 9 years ago

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.

astine• 9 years ago

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

To be fair, they are getting better about that. Git has almost as good support as TFS in Visual Studio these days and MS is even integrating Linux of all things into its latest Windows releases. If that trend continues, MS will eventually be much less of a walled garden.

teh_klev2• 9 years ago

Something I've written 4 years ago will still run and compile like yesterday even if I've abandoned it in the mean while.

This.

I wrote a bunch of our (internal, non-internet facing) billing and automation code back in 2003 in C#1(.1?)/.NET 1.1. As we've gradually moved to .NET 4 the code still just works and when we need to it recompiles against newer framework versions with no errors.

Even the assembly of the Data Access Application Block [0] used back then for some of this stuff still works fine, the last time it was recompiled was for .NET 2.0 around 2006, but the IL runs without any trouble on .NET 4.6.

This is a mission critical codebase that doesn't change very often, but when it does it's imperative that it can when necessary rebuild against each major .NET framework update with no dramas.

Stability and confidence is key for us and MS have been very good at that, even when older features are deprecated/obsoleted.

Finally....

...just over two years ago when we were pushing the last of our hosted dedicated server customers to upgrade from Windows 2003 to Windows 2012R2 there were a few folks that were still running websites written in ASP.NET 1.1/.NET 1.1 on 2003. There were probably 40-50 sites and a sprinkling of Classic ASP just to make life interesting. Most customers didn't want to go through the hassle of recompiling and redeploying.

Now whilst there is a .NET 1.1 release you can run on Windows 2012, I really didn't want to be supporting three framework versions (1.1, 2.0/3.5 and 4.x) and CLRs. Having successfully migrated bucket loads of ASP.NET 1.1 sites to 2.0 in the past, from experience, I was fairly confident the 1.1 binaries would run just fine on .NET 2.0 which is the minimum version of .NET that ships in Windows 2012 and the IIS admin bits know about. After a week or so all of these old 1.1 sites were up and running on .NET 2.0 in IIS Classic Pipeline app pools, no recompilation needed and except for one site that used an ancient third party PDF component, all was well in the world.

Now whilst .NET may seem unexciting enterprisey stuff, it's a testament to how much the .NET folks care about stability and backwards compatibility. I'm fairly sure, and I know for sure, I couldn't do these seamless transitions if these codebases were written in PHP (for example).

[0] https://msdn.microsoft.com/en-us/library/ff649538.aspx

sharemywin2• 9 years ago

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?

NoGravitas2• 9 years ago

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

nikon• 9 years ago

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.

mack73• 9 years ago

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.

faragon• 9 years ago

TL;DR: ad hominem arguments.

sharemywin2• 9 years ago

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.

nedsma6• 9 years ago

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

tonyedgecombe2• 9 years ago

On the other hand you could probably spread yourself too thin as well.

aNoob7000• 9 years ago

Yep.

nedsma6• 9 years ago

With mainstream programming jobs that can't happen. Any proficient JavaScript developer can pick up in matter of weeks/days any JS framework, or would you like to keep on insisting, e.g. on Angular? If you were primarily a .NET developer for the last three years, and then you switch the stack for a year/two, would you miss out something from the .NET world? Hardly. The foundation and good programming practices change slowly. The previous experiences are burned in in the memory and don't seem to fade.

pjmlp7• 9 years ago

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.

nedsma6• 9 years ago

Great!

I'm talking about experienced developers like you, who know what it takes to be productive/get things done.

First you learn grammar and semantics of some new language, then you want to build a product. From your past experience you can tell what's necessary for solution to be successfully created (all the things you mentioned and some more). Make it a list, evaluate, revisit your best choices as you go. Once you find yourself happy in the new environment, you're in a position to more accurately determine which of the tools now is better for the job.

tonyarkles• 9 years ago

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.

wvenable6• 9 years ago

I'm actually a bit tired of switching platforms all the time. You spend more time re-getting up to speed than producing applications. Although I'm not a fan of JavaScript-everywhere I can see the appeal when I want to do work on Windows, Linux, Android, and Tizen applications and don't want to switch between a dozen different technologies and frameworks. It's too much for a single person to manage.

We have to accept that there is a real human limitation. You cannot be an expert at every technology that exists. If you try, you'll be forever spinning you wheels and never actually build anything.

nedsma6• 9 years ago

You cannot be an expert at every technology that exists.

Why would that be a goal? I'm not saying that mediocre work is a good thing either. A really competent programmer in one language/framework will find out that obtaining a comparable level of competency in another isn't surely going take as much time as one has needed when initially starting. Why? Because programming activities affect programmer's mind and enable deepening of mind's properties such problem solving, organization, logic, attention to detail, creativity, focus etc.

bartread• 9 years ago

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• 9 years ago

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

mannykannot• 9 years ago

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.

alistproducer2• 9 years ago

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.

elorant• 9 years ago

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-AL2• 9 years ago

Compared to the technologies people learn today, .net is a glacier.

insulanian• 9 years ago

I'm still using C# 4.0 for my projects.

I think you're missing out a lot.

AngeloAnolin• 9 years ago

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

smt885• 9 years ago

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.

paulirwin2• 9 years ago

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.

smt885• 9 years ago

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, we know. As I said, we had multiple people who had been using .NET and EF for years.

Yes, this can be terribly inefficient

I wasn't talking about efficiency. We're not at a stage where we're optimizing our queries. We just want code that works and is inexpensive to maintain.

In this case, we just wanted EF to work at all. We never figured out why it wouldn't work. We got a weird, opaque error message. Our code was laughably simple: create the context, update a row, SaveChanges. That's it.

robodale2• 9 years ago

I wish I could circle this response and write EVERYONE READ THIS. Agree with you 100%

Flott• 9 years ago

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

teh_klev2• 9 years ago

Dapper

This is all I use now, it's fast and lightweight, works with MSSQL and MySQL and I'm not averse to getting down and dirty with dynamic objects instead of having to define POCO's upfront. It's a hugely productive tool for me. I also don't mind writing raw SQL statements and I don't need to worry about having to abstract away the DB because these apps are targeted for specific DB products.

Before Dapper when I went in search of ORM's for .NET I tried NHibernate, but too much config ceremony. Then I had a short dalliance with LINQ to SQL, it wasn't terrible, but it was a bit of a pain to work with legacy DB stuff, same with backing in new table columns/changes (sure I could edit the .dbml files directly then regen the .designer.cs, but meh).

I had a look at EF 4.x but at the time its support for enums was non-existent (it took until 5.0's release in 2012) and that was a deal breaker. It was also just too much of a monster and got in the way, and I found myself more often tha not executing SQL directly via the data context.

So yes, Dapper, thank you Mark Gravell, Sam Saffron and Nick Craver for with wonderful tool.

guitarbill3• 9 years ago

I haven't touched C# or .NET in ages, but Visual Studio has always been awful. There was a free IDE called SharpDevelop that was miles better. I don't know if it's kept up, and I can't exactly recommend it after not working with C# for so long. Just agreeing with the Visual Studio pain.

WorldMaker3• 9 years ago

Personally, I'm very happy with VS and feel the performance focuses in the last three major versions continues to pay off.

SharpDevelop still exists, though I'm not sure I'd recommend it as it seemed to get stuck in a time warp somewhere around 2012.

MonoDevelop forked from SharpDevelop. Xamarin Studio forked from MonoDevelop. In an interesting twist of fate, Xamarin Studio is now Visual Studio for Mac and looks to be integrating a lot more of Visual Studio in future releases.

artmageddon2• 9 years ago

This makes me feel a bit better about sticking with ol' ADO.Net.

sklarsa• 9 years ago

Depending on your use case, that can have disadvantages too. For example, I imagine it would be quite difficult to refactor your code around any database schema changes if you're writing raw SQL queries in ADO. Many modern ORMs, including Entity Framework, have a "code-first" approach, allowing you to modify your mapped objects in code and then programatically perform the related schema changes in the database. In a compiled language like C#, this makes refactoring fairly painless. Also, ORMs do reduce a lot of boilerplate code needed to perform CRUD operations, reducing the potential of introducing new errors into your data access layer.

While I understand that ORMs are not for everyone, and certainly have their limitations, I think that in this day in age, they're at least worth investigating. Even in the .NET space, there are other ORM options to choose from aside from Entity Framework.

zip12342• 9 years ago

Depending on which version of EF you are using, it is just a wrapper around ADO.Net

juliangoldsmith3• 9 years ago

What sort of problems have you had with Visual Studio 2015? I've been using it for a while, and have found it (mostly) pretty nice to work with.

I can't say I've worked with Entity Framework before, but I've always believed it to be an abomination. Looks like I'll continue to avoid it.

soundwave106• 9 years ago

I wouldn't call it an abomination per se, but it is a very heavy ORM in my opinion. It works well for CRUD, but can be a dog in performance for very complex queries. (These type of queries can be offloaded into stored procs, of course... but inexperienced developers might "forge ahead" and create low-performance code in EF, unfortunately...)

From my perspective, my biggest problem with EF is that Microsoft seemed to half-abandon any concept of "light weight data access layer" (like the previous Linq to SQL), and pushed Entity Framework as The One True Way to call the data layer. EF is definitely suitable for Microsoft's "core audience" of large, enterprise-y CRUD apps, but IMHO it's rather heavy for a simple web page with a few data calls. Fortunately there's things like Dapper that are great for small quick apps.

smt885• 9 years ago

Builds randomly hang, dependencies disappear when changing branches, weird errors that tell me to reinstall the IDE... everyone on my team has them.

We now have a VM image that we launch in the cloud whenever we need to reset VS. It's ridiculous.

jhimes• 9 years ago

I work as a consultant at a large fortune 500 company and have been writing .net for years. My colleagues are top notch senior .net and Java developers, not because they came from a bank, because they all have been writing .net since it came out, ARE GOOD AT IT, and regularly practice other languages. This post erks me.

I will admit, VS 2015 has some issues, its less reliable than its predecessor, (the new nuget package manager is horrific) however its still an amazing IDE. I will also admit EF can have a bunch of little frustrating facets if you don't know all the intricacies. Read an EF book. What I will disagree with you on is that senior .net developers have never seen the sun and will never know that their lives suck because they haven't experienced anything else.

We have an enormous code base in .net with priority in millions of dollars, we use EF at the core and we do not run into issues like you describe because we know how its used. This tells me your developers, while maybe very good developers in their own right, are not as experienced in .net like you say.

You said you love EF when it works, well learn why it isn't working when its not working, and you will fall in love I promise.

smt885• 9 years ago

I have used other stacks that are less magical and just as efficient. Abstractions don't have to be complicated or opaque.

You say to learn the stack better? Fine. That huge learning curve makes turnover expensive and drastically limits the pool of devs I can hire.

With, say, Python, I can hire any smart dev and she can learn the language and ecosystem enough in a few weeks to be productive.

dep_b2• 9 years ago

EF is really really bad. I will never touch it again. I really don't have any reason not to use something more sane like Dapper. Spend hours on getting complex queries to work just to discover they're horribly slow. I'm not a huge sproc advocate but yes sprocs over EF when doing complex queries every time if I need to choose.

rb808• 9 years ago

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.

pawadu5• 9 years ago

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

wvenable6• 9 years ago

It's not viable yet but lets hope it gets that way.

oblio• 9 years ago

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

martamoreno• 9 years ago

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.

robodale2• 9 years ago

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.

okreallywtf• 9 years ago

That has been my observation as well. You can have an express (express was popular at the time I was working with node, not sure whats hot right now) app up in minutes but when it came to adding authentication, dependency injection, unit testing and really making it production ready it took a dozen modules and a lot more of my time. Part of that was just maturity I'm sure but I kind of felt like I was just taking high quality parts and duct taping them together. In .NET (webapi2 that is) it seems like I have a little less choice about what parts to use but they are also made to fit together and do so nicely without a lot of tinkering.

dagw• 9 years ago

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• 9 years ago

https://docs.microsoft.com/en-us/aspnet/core/tutorials/web-a...

_pmf_• 9 years ago

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• 9 years ago

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

atemerev• 9 years ago

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.

JamesBarney• 9 years ago

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.

gjmacd2• 9 years ago

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

Illniyar2• 9 years ago

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.

gjmacd2• 9 years ago

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.

gentleteblor• 9 years ago

JobRudder is an ASP.NET/Sql Server app running in the cloud. It works and it works really well (tooling between visual studio and azure is amazing).

[1] https://jobrudder.com

vuyani• 9 years ago

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?

yks• 9 years ago

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

A response to “Why you can't be a good .NET developer” (2016)

Related Stories