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