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. (16 Aug 2022) How Discord supercharges network disks for extreme low latency
  2. (02 Jun 2022) BonsaiDb performance update
  3. (14 Jan 2022) Are You Sure You Want to Use MMAP in Your Database Management System?
  4. (09 Dec 2021) Why IndexedDB is slow and what to use instead
  5. (23 Jun 2021) The performance regression odyssey
  6. (27 Oct 2020) Investigating query performance issue in RavenDB
  7. (27 Dec 2019) Writing a very fast cache service with millions of entries
  8. (26 Dec 2019) Why databases use ordered indexes but programming uses hash tables
  9. (12 Nov 2019) Document-Level Optimistic Concurrency in MongoDB
  10. (25 Oct 2019) RavenDB. Two years of pain and joy
  11. (19 Aug 2019) The Order of the JSON, AKA–irresponsible assumptions and blind spots
  12. (10 Oct 2017) Entity Framework Core performance tuning–Part III
  13. (09 Oct 2017) Different I/O Access Methods for Linux
  14. (06 Oct 2017) Entity Framework Core performance tuning–Part II
  15. (04 Oct 2017) Entity Framework Core performance tuning–part I
  16. (26 Apr 2017) Writing a Time Series Database from Scratch
  17. (28 Jul 2016) Why Uber Engineering Switched from Postgres to MySQL
  18. (15 Jun 2016) Why you can't be a good .NET developer
  19. (12 Nov 2013) Why You Should Never Use MongoDB
  20. (21 Aug 2013) How memory mapped files, filesystems and cloud storage works
  21. (15 Apr 2012) Kiip’s MongoDB’s experience
  22. (18 Oct 2010) Diverse.NET
  23. (10 Apr 2010) NoSQL, meh
  24. (30 Sep 2009) Are you smart enough to do without TDD
  25. (17 Aug 2008) MVC Storefront Part 19
  26. (24 Mar 2008) How to create fully encapsulated Domain Models
  27. (21 Feb 2008) Versioning Issues With Abstract Base Classes and Interfaces
  28. (18 Aug 2007) Saving to Blob
  29. (27 Jul 2007) SSIS - 15 Faults Rebuttal
  30. (29 May 2007) The OR/M Smackdown
  31. (06 Mar 2007) IoC and Average Programmers
  32. (19 Sep 2005) DLinq Mapping