A response to “Why you can't be a good .NET developer” (2016)(ayende.com)
ayende.com
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
199 comments
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?
Where can one find these .NET shops that strive to make use of the latest developments?
>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.
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.
One of the things I would always recommend if you are working in the Microsoft stack at bleeding edge I would start trying to talk to the evangelists sooner than later. It feels on the outset that this is how their product cycles work so making friends with these people can help you get past the 'on rails' presentation of the demos. I say this as someone who goes to in-person presentations from these evangelist types and poked holes in their demos and got satisfactory admittance of guilt or meaningful follow-ups.
>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
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
You get to pick the best tool for the job, thats the biggest difference.
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.
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.
This. I just read Bezos' 2016 shareholder letter, and I feel like allowing uni-technology teams is one of the ways you become a legacy business.
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.
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.
Not to get off topic - but what is your opinion of Salesforce?
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.
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.
(I'm not the person you are asking but I'm working now on reversing my employer's failed venture into SFDC)
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...
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...
> 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~...
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~...
Salesforce to me has been a very "emperor has no clothes" type tech.
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.
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.
From my experience is a bloated old technology, with terrible UI and even worse developer experience.
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.
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.
> even worse developer experience.
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!
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!
As a former .net developer who is now a Salesforce consultant, I can speak to this. People adobt Salesforce because they can imlement 75% of their mission critical processes with point and click on a system where they don't have to worry about server configuration or hire a DBA.
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.
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.
I'm going to pass somewhat :)
.. 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.
.. 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.
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.
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.
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.
Allow me to offer a counterpoint. Plenty of great developers blog and give talks while getting things done, you may enjoy post by John Carmack, talks by Sandi Metz, talks by Rich Hickey, talks and books by Carin Meller[1], talks and posts by Vaidehi Joshi[2], Kent Beck, or Dave Thomas or Elixir and Ruby fame[3]. Now, I don't know much about .Net, but in the communities in which I'm involved, the best and brightest are constantly writing, and speaking, and building great things.
[1]http://gigasquidsoftware.com/#/index [2]https://dev.to/vaidehijoshi [3]https://www.youtube.com/watch?v=5hDVftaPQwY
[1]http://gigasquidsoftware.com/#/index [2]https://dev.to/vaidehijoshi [3]https://www.youtube.com/watch?v=5hDVftaPQwY
People you know about != the best. John Carmack is significantly above average, but unlikely to be in the top 1,000 developers world wide. Linus Torvalds is a very good developer, but world class at managing developers.
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."
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."
You're moving the goalposts here, you originally said "Great developers avoid the beading edge, which let's them get stuff done. They don't give talks or write blog posts..."
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.
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.
I am fine calling someone Great and a Developer without assuming that also makes them a Great Developer. A Developer can be an 'awesome' writer, speaker, teacher, researcher, VC, evangelist, artist, or project manager without being a 'awesome' Developer.
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.
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.
I'm not so sure you can have millions of people apply and easily get to the top 10. Even if you look at something metric driven like sales, being the best salesperson in the world last year isn't a good indicator of next year's performance. If you think about something more knowledge driven, how would you find the best physicist? The most cited? The most published? Do you grab the most recent Nobel winner? I think even with baseball you might have trouble putting together a definitive top 10.
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.
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.
In your baseball example I think you could pick 100 people and then say the top 10 on some criteria are on that list. I don't think we can say the top 10 are on this list of the top 100 for programming or most other professional fields.
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.
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.
> John Carmack is significantly above average, but unlikely to be in the top 1,000 developers world wide.
"Don't you blaspheme in here. Don't you blaspheme in here!" /Aretha
"Don't you blaspheme in here. Don't you blaspheme in here!" /Aretha
You could use this template to complain about almost any programming job, not just .NET jobs.
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?
This has to be the case. Professionally, I've always found myself lacking in advanced projects to cut my teeth on, but also too time constrained doing the routine work to be pursuing anything "interesting."
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.
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.
I wonder sometimes if, in the quest to make things "interesting" again, we fall into the trap of making the uninteresting things so damned complicated that we find that scut work foisted back on us, because the tooling has become to complex.
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.
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.
Agreed, we may be doing interesting work horizontally, reimplementing things that have already been solved. (Maybe this is natural in the evolution of things, searching for a breakthrough.)
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.
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.
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.
We're a marketing startup that uses the .NET stack and it's been a key driver in building a better product faster.
> 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.
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.
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.
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.
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.
I have quite a few of them running on my S3.
> 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.
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.
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.
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.
> the language/stack choice is orthogonal to the quality of the code base
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.)
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.)
> 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.
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.
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.
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.
> 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.
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.
Don't worry so much about the quantity (learning as much as you can) than the quality. You could basically kill yourself trying to learn every modern piece of technology. It's not really worth it -- it'll be obsolete before you get a chance to actually use that knowledge.
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.
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.
Yeah I just worry that being tied to C#/.NET that I'll be stuck with the same sort of job (and the knowledge won't transfer to other stacks)
You will always be stuck to a certain stack, specially in countries like Germany where what HR department cares about is what language/tooling you did use during the more recent years before the interview.
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.
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.
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.
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.
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.
Having been on both sides of the fence I came to realize that in spite politics, I rather work in enterprise environments than startup ones.
Maybe it is an age thing.
Maybe it is an age thing.
Another downside however is as those jobs go away, the numbing of skills can come back to bite at finding jobs down the road.
Please define "good pay" and "good benefits". For me, the "pay" part would have to be substantial. The tangible benefits I currently have are average. The flextime is fantastic though (I work remotely at least once or twice a week and there is a very flexible notion of "business hours").
Everything is relative. I think its hard to generalize. There are lots of startups that are much more lenient with remote work, and many that embrace the basecamp-style company values. In general, if you are not in SV or maybe NYC, big open source job markets, you tend to hit a pay wall pretty quickly.
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.
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.
(Having only been at one place thus far my opinion may be different)
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.
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.
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.
I'm constantly curious about what other people are working on, or if they are re-writing the same CRUD app over and over.
>What would you consider a good developer?
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.
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.
>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.
Bingo, no matter which language is , bad culture will still suffocate you. Nothing to do with specific programming language / environment.
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.
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.
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.
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.
"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.
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.
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.
No different than the Java shops I've seen.
Very different in my experience; there's a lot more on maven central, because the toolchain and other popular components (e.g. mariadb) are freely available, so you can very easily spin up the same environment at home.
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
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
> 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.
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.
The bigger problem isn't that people don't update. The bigger problem is why people don't update.
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.
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.
This isn't a .net problem. This is an almost every software product known to man problem.
I am not sure why, i started VB.Net and somehow i dont like any other language i can write an app (CRUD) in a week. Never had an issue , help is available code is like english to me most of the time.
Its kind of like appliances. Everyone likes shiny new appliances.
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.
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.
> 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.
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.
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.
> 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
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
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.
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.
I find it bizarre that the original blog entry was seen to be blaming the technology, quite the inverse in fact.
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.
Everything sucks if you do it badly.
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.)
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.)
> 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.
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.
QFT: Everything sucks if you do it badly.
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.
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.
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.
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.
> 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.
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.
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".
---
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".
[deleted]
> 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.
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.
Just trying to constructively help the community and build the body of knowledge around EF. I'd be interested in seeing example code to reproduce your issue, and I'd be happy to look into it. If there is a case where EF errors updating records, it would be good to help people know what to avoid or how to work around it, or possibly even submit a fix to the project. I've never seen a scenario that you're describing in my years with EF so it intrigues me. If you can make a gist or something that would be awesome. Or at least the error message as you described. I assume it was something like "An error occurred updating the entities", in which case the error message(s) from InnerException would be needed to diagnose.
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.
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 wish I could circle this response and write EVERYONE READ THIS. Agree with you 100%
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.
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.
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.
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.
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.
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.
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.
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.
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.
EF Core is much lighter-weight and tries to be a best of both worlds, pushing some of the heavier stuff into extensions/plugins rather than out of the box. This is why some of the fans of the heavy old EF dislike EF Core, but I'm happy EF Core takes an overall lighter-weight approach.
There's no reason you can't keep using Linq-to-SQL. It's not the new hotness, but it still works just fine. If you're doing SQL Server, I wouldn't see any reason not to use it.
I may have Stockholm syndrome, though.
I may have Stockholm syndrome, though.
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.
We now have a VM image that we launch in the cloud whenever we need to reset VS. It's ridiculous.
Fascinating. Are y'all using ReSharper by any chance? Every time I've seen those sorts of problems in VS and helped colleagues diagnose them it has been ReSharper causing them directly or indirectly.
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'm not a fan of ReSharper, never install it, and it fascinates me how often VS gets blamed for ReSharper's bad behavior.
Not using ReSharper anymore. I absolutely loved it when I used it though. I'm not sure if I caused any problems or not, but I'm not taking a chance anymore.
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.
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.
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.
This makes me feel a bit better about sticking with ol' ADO.Net.
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.
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'll have to admit the lack of ability to do quick refactoring has bitten me on more than one occasion.. :/
[deleted]
Depending on which version of EF you are using, it is just a wrapper around ADO.Net
"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.
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.
Yeah, it's definitely a culture problem, not a platform problem.
The culture that leads to Cobol programs running banks with expiring developers.
How exactly would you rewrite a 10M-line codebase in a new language, without any sort of bugs?
More importantly, how would you convince management to allow you to do so?
More importantly, how would you convince management to allow you to do so?
That's the whole point: you shouldn't get into this situation in the first place, and the reason you did is that you've got a culture of short-termism that doesn't place enough weight on maintainability. This disaster's been 40 years in the making, and everyone thinks they made the right call.
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.
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.
A culture of short-termism isn't the problem here. The problem is that the business rules that the code needs to implement are ridiculously complex.
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.
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.
Well, it pretty much is. Everyone's concerned with how many eggs they're dealing with. But the basket's falling apart. It's not like we haven't already had situations where banks have found themselves completely unable to process payments for weeks at a time. And it's only going to get worse.
Agreed. The type of culture that gives us classes like "AbstractSingletonProxyFactoryBean", etc.
I never did C# or Enterprise IT but I think that ridiculing explicit naming misses the point.
I don't think it's the explicit naming that's being ridiculed, it's the bingeing on design patterns and baroque enterprisey design that Java, especially, is infamous for.
I don't know the first thing about C#, but in Java, you can't sometimes avoid fancy design patterns - eg. using Observer where in C++ you could just depend on late binding.
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.
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.
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?
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?
Can we just ignore this guy now?
The irony being, Oren clearly doesn't ignore Rob, since he's paid him a fair bit to work on Raven over the years.
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!
Like you can't do composition in C#. You can't blame language for your shitty design!
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...
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...
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.
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.
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.
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
[1] https://jobrudder.com
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.
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.
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.
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.
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.
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.
It's not about your "full right". It's about whether or not it leads to civil discussion.
The biggest problem with discourse is that we think we know what the other person is thinking.
The biggest problem with discourse is that we think we know what the other person is thinking.
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.
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.
so let's not pretend this is one.
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?
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?
>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 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 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:
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."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.
Sigh. This kind of arguments is way too common.
> 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
FTFY
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.
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.
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)
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.
Nothing to do with the language/framework, but its adopters.
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.
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.
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.
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...
[1] http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...
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.
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.
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.
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'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.
Being an IDE person, I never bothered searching for C# on Emacs.
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.
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.
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.
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.
> 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.
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 agree. Getting competent in another language/framework isn't difficult -- I've done it more times than I can count. I agree having a few different perspectives is good; learn a functional language, learn assembly, 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.
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.
I agree with you and I'm not dismissing. Each stack has its own share of problems and intricacies, but some are more complicated (.NET, JVM languages). Speaking from my own experience, building Java/.NET inter-operable web services having involved WS-Security extensions (STS, SAML assertion) wasn't quite pleasant.
Other stacks follow different programming schools of thought and may result in different approach to a problem.
Other stacks follow different programming schools of thought and may result in different approach to a problem.
I'm a firm believer in using the right technology for the problem rather than simply the technology that you know best. I'm actually hoping that .Net becomes more appropriate for more tasks (especially on Linux) but for now that's not the case.
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.
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.
On the other hand you could probably spread yourself too thin as well.
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.
Angular is actually a modern stack in enterprise projects.
Only this month I became aware of RFPs for a JSF one and a ASP.NET MVC 4 one.
Only this month I became aware of RFPs for a JSF one and a ASP.NET MVC 4 one.
Sure it is, but it will eventually give up in popularity. Enterprises will then accordingly update their stack. I have a rule which says: if an established tech. community (built around particular subject) isn't screaming about some new change, it's probably not a big deal.
Agreed. It's a lot of work rewriting an application with hundreds of thousands of lines of code and hundreds of screens every six months to chase the slightly-stale thing in front-end world.
Angular is part of our .NET stack at our company. We are starting to rewrite bits of our newer projects to Angular 2 now too.
Yep.
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).
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).
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
[0]: http://www.loper-os.org/?p=69
Person 1: Because a lot of .NET teams are like...
Person 2: Wrong! Because not all .NET teams are like that.
Person 2: Wrong! Because not all .NET teams are like that.
The problem is the generalization over the stack instead of the type of company.
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.
Now, it just so happens that as general frameworks go, IMO C#/.NET is the signature Les Paul.
Oh no you did not just go there... :) I thought Java was the one everybody tried to copy :)
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.
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. <><
> 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.
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.
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.
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?
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!
> 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!
Personally I enjoy knowing my paycheck comes from the sale of products and not ad revenue or investors.
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.
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.
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.
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
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.
Real artists also improve.
Toilets ship. Wouldn't want to make me eat what comes out, no matter how much it's ... shipped.
Toilets ship. Wouldn't want to make me eat what comes out, no matter how much it's ... shipped.
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.
[deleted]
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.
Compared to the technologies people learn today, .net is a glacier.
> I'm still using C# 4.0 for my projects.
I think you're missing out a lot.
I think you're missing out a lot.
.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.
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 is bad on most platforms, it doesn't seem to be a solved problem yet.
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.
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.
What exactly is wrong with NuGet? It's very simple, I think you just didn't give it a chance
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.
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.
So far what I have seen with .NET project files is that: people modify them, VS generates code into those files, and they contain a lot of stuff. As a result, they're very painful to manage when trying to troubleshoot issues. Then, because the project files get modified all the time it's a constant source of conflicts in version control.
If project files get modified all the time then either you're constantly moving, adding, or removing files from the project, or constantly changing configurations and build settings. Neither should really happen constantly.
This is an issue addressed in the new .NET Core project templates, which are organized to limit the times VS would touch them.
I run into more problems with npm than I do with nuget. It baffles me that I need a package to better manage a package manager...
What do you think of dependency management in .Net Core?
TL;DR: ad hominem arguments.
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.
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.
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.
> 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.