A response to “Why you can't be a good .NET developer” (2016)
ayende.com
ayende.com
> 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.
Where can one find these .NET shops that strive to make use of the latest developments?
We're a marketing startup that uses the .NET stack and it's been a key driver in building a better product faster.
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
One place I worked, every solution we did had to shove at least 2 of these ingredients into the finished product: 1) .NET, 2) SalesForce, 3) SAP, 4) BizTalk ... frequently it had nothing to do with the merits/needs of what we were tasked to build.
It was simply an equation of having an IT department with these teams, and the department head for each were competing for budget and would inject themselves into the solution or their department would shrink and disappear.
Once "which language will we write this in?" becomes equated to "which team gets this work?" then your company is headed down the bad path. Because now technology choices will be driven by management politics instead of technical aptness.
We are just working on an integration/implementation with one of our systems, and it's quite a drag uninteresting. I don't quite understand the hype behind it, and since our motto (and other people I've spoken to) is "We're just going to move it into Salesforce!" my resentment towards it grows.
It is also unbelievably customizable, with one click plugins that even your grandma can add, and practically anything you can wish for already built for you. It's also extremely familiar to practically every salesperson or management out there.
Basically Salesforce is to CRM what Wordpress is to CMS - the easiest one for non-technical people to use.
The trouble is that the other 25% of the functionally that doesn't fit into the Salesforce mold is hard to come by. Partly due to platform limitions. Mostly because developing on Salesforce is littered with pitfalls and requires intimate knowledge of how the platform works. Most "developers" out there are business analysts/admin who after writing a simple trigger were transitioned into a developer role. I very rarely run into other people with CS background.
Ha ha I actually had to work with it 6 months ago at a late stage startup.. What they needed was a simple apex trigger.. it took 30 min to write on a demo account.
.. but it took us a week to find out we couldn't do it because of the version of SF that we had, and an upgrade would 6x the cost of their monthly licensing cost.
It was a really bizarre dev experience. Really crappy errors!
Business and Sales people love salesforce. It promises instant business gratification via enforcement of best practices through a single unified platform. It also promises to cut down the need for in-house software development, since everything is promised to work out of the box with some point and click configuration tools which the SF admins can easily work on (their slogan is or used to be "no software"). However, as soon as the company realizes that the standard SFDC solutions don't quite meet their business model, that's when the need for custom SF development comes up which is very restrained by APEX/SOQL capabilities and is not cheap. This is often the point where many businesses back track to custom solutions and then build messy integrations that forces the two systems to pass data to each other...
I know what you mean there...lots of DB work and json payloads has been what we are working with. Most of our work is completely custom, so it's been ~interesting~...
It demos well, and you can do some basic things with it. But then you always end up hiring someone to do custom development. So the whole appeal of a point and click platform goes away.
.. This was 6 years ago and I didn't work with it enough to really have an educated opinion. The department that used it thought it was revolutionary technology but honestly most of their devs were rejects/burn outs from the 'more real' engineering teams, to put it mildly.
What we saw in our team (.NET) was that data became siloed and was awkward to use. It was also really challenging to build responsive applications when you had to interact with clunky web services. User experience was absolutely awful the times when we couldn't just send it async.
... that said, if I had the opportunity to architect something like that, I would have rather opted to keep the data elsewhere and just push it to SalesForce when it changes.
I don't blame the company, of course, but I wonder if it isn't sound in terms of business to amortize some of that risk by considering that risky projects let employees self-train and learn new skills that could be of value.
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.
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.
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.
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.
[1]http://gigasquidsoftware.com/#/index [2]https://dev.to/vaidehijoshi [3]https://www.youtube.com/watch?v=5hDVftaPQwY
It's a classic catch-22. Self promoters are by definition getting less done, but without that promotion your never going to hear about them, just projects they worked on. Michael Jordan was better in very public ways, the absolute best developer at Verizon, Delta, or the DoD are not spending time competing under spotlights.
PS: I am not a great developer, but I have worked with people that would blow your mind. "We stopped testing his code years ago."
"Don't you blaspheme in here. Don't you blaspheme in here!" /Aretha
And great != "the best". I don't even know how you could define the best at programming. So, I listed some great developers. John Carmack's old code was literally in multiple textbooks I had in grad school, software engineering classes taught Beck's essays. If you ask anyone who's ever work with Sandi, they'll tell you she's one of the best in her domain. All of the listed folks are broadly praised by peers and former coworkers. I'm not sure how else to define great. And, on top of that they are all prolific writers/speakers.
I would also argue that as a matter of tradecraft, writing material that advances the craft and aides in training the next generation of developers is part of what makes one great. Is there someone in the basement of some 3 letter agency that can unroll a loop better than Carmack, sure I'd bet money there is, but being great is about more than that, IMHO.
Now you can argue about what advances trade craft, but having impact is an extrinsic property not an intrinsic one. A lottery winner was lucky, but luck is not some property they have that's going to influence the next coin flip they do. Similarly your measuring impact not intrinsic property's.
Suppose Google chose to spend a billion dollars building a dream team to replace JavaScript with something better. What would the best team they could possibly put together and how much would that resemble the best possible team Blizzard could put together to build Starcraft III. Further out field the department of Energy could possibly put together to simulate fusion reactions. And would anyone make all three lists.
PS: I guess my point is in other fields you can have millions of people apply and get to the top 10 in the field. Programming 'Greats' are a lesser thing selected by more than just skill.
Coming back to whether or not writing well about technical topics indicates ability, I think it's a good proxy. If you can clearly explain how to do a difficult thing well, then you necessarily must be able understand and probably by extension do that thing. Clearly this breaks at some point, but I think it holds true for software development.
However, in my mind that does not mean the top 10 are not out their just that we can't rank the field that way. Which does not mean their is not actually 10 best programmers for any given task. Nor does not mean we should pick some proxy and say these people are the top paid and therefore the top 10 are on this list of 100 top paid programmers or something like that. Because, while ranking people like that might be amusing or fun it's simply not accurate which is my core problem with your line of thinking. It basically says I can't get what I want, so I am going to pretend that what I want is what I can get.
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.
Bingo, no matter which language is , bad culture will still suffocate you. Nothing to do with specific programming language / environment.
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.
Maybe it is an age thing.
I've yet to come across someone who has been "happy" with their benefits package. I don't even take advantage of mine because it's such a large chunk for a single person, and yields no incentives - these I would likely consider tangible benefits (aside from the obvious). I could see it being nice if I had a family though, but most people I've spoken to use their significant others benefits package.
The one thing I hope to always have wherever I work is flexible working hours. I very much dislike the stigma of "oh you're not first into the office!". Maybe it's just me though who has ran into this.
It is much harder for me to find a startup that pays as well as a more traditional IT shop would pay me. I can find a 130-140k job in .NET here in South Florida with relative ease. For open source, there are maybe a handful of companies willing to pay that kind of money. In general, these enterprise places will offer very good benefits (vacation/401k w contribution/paid healthcare) and the work is not hard in comparison.
At startups, its just spottier. Last place I worked paid me same as before but didn't contribute towards my healthcare.. That was an extra $1300 / month that had to come out of my paycheck and an expensive lesson.
I'm constantly curious about what other people are working on, or if they are re-writing the same CRUD app over and over.
You can convince people you are a good developer.
It's only a title that other people give you -- there's not an objective, definitive test for it and you can use a number of methods to get that title (actual technical skill, social skills, outright fraud). And of course, if you convince a good number of people, it's much harder for you to lose that title.
I know that sounds cheeky but if you look at interviews and how ridiculous everyone thinks those are, you know we don't have a good technical test to actually prove if anyone is a good developer because the test is so different than actual day-to-day operations we do. If we knew about that test, we'd be using it, and we'd have a hell of lot less "INTERVIEWING IS BROKEN" blog posts.
All of those tests are built on opinions on what a good developer ought to be, and there are tons of variations. Being a good developer and a good computer scientist are two distinct things with some overlapping skills.
The real test is just putting someone in the position but that can be untenable for both sides since they cannot afford to spend the time and money for that sort of accuracy.
I have less knowledge about business value but anything that adds to the company's sustainability or profitability or efficiency (to include non-profit/not-for-profits) is likely adding business value.
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.
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.
technically true, but in reality there's going to be a correlation between technology stack used and development practices. whether that's Javascript/Swift at super-agile-brogrammer $startup or Java/.NET at Enterprise Corp, Inc. stereotypes exist for a reason.
he's what you can do: evaluate how much you hate an average/mediocre/horrible workflow in said language (for me, I hate anything Javascript, no matter how smart/great the devs are. some people it's the verboseness of Java, etc).
then, go work for/with people you've worked before. i have yet to find another way of evaluating company culture truthfully. (interviews just don't cut it, too much potential to lie.)
That, and, an interview is a handful of hours at most. There's no way to really evaluate a culture in that amount of time, even if nobody is hiding anything. The real problems, the frustrating politics, etc only become apparent after you've been "in it" a while I think.
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.
It's one thing to be stuck with terrible non-moving technology but .NET is a good technology stack that is progressing in the future nicely. Conceptually you'll be fine.
Usually knowledge learned on side projects are not taken seriously by them, as they weren't on the job. Oh and they love paper (certifications of all sorts).
Algorithms and data-structures always transfer to any stack. Learn the CS mathematical foundations of them.
A good way to avoid being stuck with a certain stack as you put it, is working for a consulting company. It is way easier to jump stacks when switching projects than than trying to convince random HR department of what you actually know.
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.
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.
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
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.
Updates often cause things to break.
If you want structural changes to force updates, you'd better also have structural changes to force stability of those updates. Otherwise you'll find that you've locked out certain types of customers.
It is terrible when people keep old fridges around. They are less power efficient. They take longer to reach a cold temperature. They are less stylish.
Still, it sure does suck when your fridge breaks unexpectedly and its time to buy a new one. The only difference between the fridge and the software is that the fridge is almost certainly cheaper.
Yes, but it also costs time and energy to create a fridge in the first place. If you are just continuously buying new fridges every few months, you will be wasting a lot of energy, because you didn't fully utilize the energy put into creating the previous fridge.
RoI is the rule in business. You need to get returns out of your investment. If you have to continuously pour more money into the hole to keep it "up to date", that delays your returns. Sometimes to the point of making the entire thing "unprofitable", which is a very bad place for a project to be.
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.
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.
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).
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.
Everything sucks if you do it badly.
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.)
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.
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.
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.
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.
My most likely paths of diagnosing that issue would be to make sure the object is properly tracked in the context, ensure there aren't data type issues (i.e. having a System.DateTime value be default(DateTime) for a SQL datetime column that is out of range), make sure it isn't trying to update a computed/identity column, look for special SQL data types (geospatial, XML), if validation is turned on at the context level ensure the properties validate against the DataAnnotations, etc.
---
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".
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.
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.
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.
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.
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.
I may have Stockholm syndrome, though.
We now have a VM image that we launch in the cloud whenever we need to reset VS. It's ridiculous.
I'm not a fan of ReSharper, never install it, and it fascinates me how often VS gets blamed for ReSharper's bad behavior.
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.
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.
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.
More importantly, how would you convince management to allow you to do so?
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.
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.
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.
Can we just ignore this guy now?
Like you can't do composition in C#. You can't blame language for your shitty design!
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...
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.
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.
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.
The biggest problem with discourse is that we think we know what the other person is thinking.
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.
That's an interesting position. Shouldn't we strive to have a civil discussion despite whatever incivility may have sparked it? Is any discussion irrevocably tainted?
I reserve the right to decide that for myself on a case-by-case basis.
And FWIW, I don't think lecturing someone else about their civility is a civil thing to do.
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."Sigh. This kind of arguments is way too common.
FTFY
At least it is tail recursion, though.
Nothing to do with the language/framework, but its adopters.
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.
[1] http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...
Only this month I became aware of RFPs for a JSF one and a ASP.NET MVC 4 one.
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.
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.
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.
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.
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.
I'm not dismissing problem solving, organization, logic, etc. But you can't dismiss the practical details like what APIs exist, what bugs they have, how do you call them, language features, platform differences, XML configuration file of the week, etc. You can only hold so much of that in your mind at once. And having that is what gives you productivity.
Other stacks follow different programming schools of thought and may result in different approach to a problem.
But the point is that having a bunch of radically different technologies for every task is far from optimal. You simply can't master them all. Right now I made a bunch of technology purchases and I'm looking at Unity development, Tizen development, and Android development all at the same time along with the usual day to day .net stuff and it's way too much. Having a single language/framework would make it a lot easier to produce a result.
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).
Person 2: Wrong! Because not all .NET teams are like that.
Now, it just so happens that as general frameworks go, IMO C#/.NET is the signature Les Paul.
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.
> 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!
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.
Toilets ship. Wouldn't want to make me eat what comes out, no matter how much it's ... shipped.
I think you're missing out a lot.
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.
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.
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.
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.