reWhy you can't be a good .NET developer

time to read 3 min | 526 words

This post is in reply to Rob’s post, go ahead and read it, I’ll wait.

My answer to Rob’s post can be summarize in a single word:

In particular, this statement:

it is impossible to be a good .NET developer. To work in a development shop with a team is to continually cater for the lowest common denominator of that team and the vast majority of software shops using .NET have a whole lot of lowest common denominator to choose their bad development decisions for.

Um, nope. That only apply to places that are going for the lowest common denominator. To go from there to all .NET shops is quite misleading. I’ll give our own example, of building a high performance database in managed code, which has very little lowest common denominator anything anywhere, but that would actually be too easy.

Looking at the landscape, I can see quite a lot of people doing quite a lot of interesting things at the bleeding edge. Now, it may be that this blog is a self selecting crowd, but when you issue statements as “you can’t be a good .NET developers”, that is a pretty big statement to stand behind.

Personally, I think that I’m pretty good developer, and while I dislike the term “XYZ developer”, I do 99% of my coding in C#.

Now, some shops have different metrics, they care about predictability of results, so they will be extremely conservative in their tooling and language usage, the old “they can’t handle that, so we can’t use it” approach. This has nothing to do with the platform you are using, and all to do with the type of culture of the company you are at.

I can certainly find good reasons for that behavior, by the way, when your typical product lifespan is measured in 5 – 10 years, you have a very different mindset than if you aim at most a year or two away. Making decisions on brand new stuff is dangerous, we lost a lot when we decided to use Silverlight, for example. And the decision to go with CoreCLR for RavenDB was made with explicit back off strategy in case that was sunk too.

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.

The reason you see backlash against certain changes (project.json coming, going and then doing disappearing acts worthy of Houdini) is that there is value in all of that experience.

Sure, sometimes change is worth it, but it needs to be measured against its costs. And sometimes there are non trivial.

More posts in "re" series:

  1. (10 Oct 2017) Entity Framework Core performance tuning–Part III
  2. (09 Oct 2017) Different I/O Access Methods for Linux
  3. (06 Oct 2017) Entity Framework Core performance tuning–Part II
  4. (04 Oct 2017) Entity Framework Core performance tuning–part I
  5. (26 Apr 2017) Writing a Time Series Database from Scratch
  6. (28 Jul 2016) Why Uber Engineering Switched from Postgres to MySQL
  7. (15 Jun 2016) Why you can't be a good .NET developer
  8. (12 Nov 2013) Why You Should Never Use MongoDB
  9. (21 Aug 2013) How memory mapped files, filesystems and cloud storage works
  10. (15 Apr 2012) Kiip’s MongoDB’s experience
  11. (18 Oct 2010) Diverse.NET
  12. (10 Apr 2010) NoSQL, meh
  13. (30 Sep 2009) Are you smart enough to do without TDD
  14. (17 Aug 2008) MVC Storefront Part 19
  15. (24 Mar 2008) How to create fully encapsulated Domain Models
  16. (21 Feb 2008) Versioning Issues With Abstract Base Classes and Interfaces
  17. (18 Aug 2007) Saving to Blob
  18. (27 Jul 2007) SSIS - 15 Faults Rebuttal
  19. (29 May 2007) The OR/M Smackdown
  20. (06 Mar 2007) IoC and Average Programmers
  21. (19 Sep 2005) DLinq Mapping