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.
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.
Doesn't matter what he's thinking, it matters what he's saying, and what he's saying is not something that engenders civil discourse so none should be expected.
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.
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 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:
"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."
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.
Blogger 1 makes overreaching claim when talking about a general trend. Blogger 2 focuses on the overreaching claim and mostly ignores the overall point.
> 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.
"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 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.
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.
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.
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.
> 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.
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.
> 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.
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?
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.
>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
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.
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.
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.
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.
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.
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!
(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...
> 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~...
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.
.. 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.
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 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 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.
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.)
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.
>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.
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.
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.
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.
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.
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.
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."
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.
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.
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.
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.
> 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.
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.
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").
(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.
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'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.
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.)
> 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.
> 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.
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.
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.
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.
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.
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.)
> 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 is sort of inconvenient is the dependency management, and that has as a consequence many .NET shops reinventing the wheel.
Another bad thing is the presence of closed source proprietary libraries, meaning they can't be forked and adapted/improved upon. This has somehow changed lately with Microsoft open sourcing some stuff.
Dependency management in .NET is not as good as let's say, Java, Python, Ruby, node.js.
Setting up your project to use Maven, pip, gems or npm respectively is very easy. I have tried nuget, but it is not as nearly as easy to use or reason about as other systems.
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.
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.
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."
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.
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.
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
> 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.
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.
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.
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.
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.
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.
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.
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.
"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.
> 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).
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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 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.
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.
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.
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.
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.
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.
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. <><
199 comments
[ 3.0 ms ] story [ 226 ms ] threadI lol'ed.
I don't necessarily agree with Rob's post, but the idea of building a high performance database in .NET is hilarious.
Also, I get this feeling that the original poster (Rob) is the kind of guy who has zero experience outside a few web frameworks. The kind of guy that barely even knows that desktop, server and embedded exist.
I think these kinds of disparaging remarks about people don't belong in a civil discussion. If you feel that the opinion isn't worth being discussed, you can just not comment.
A guy makes a huge claim based on his very limited view of the market (while insulting everybody). I think I am in my full right to call him out.
The biggest problem with discourse is that we think we know what the other person is thinking.
The original blog is spewing some pretty stereotypical bullshit you'd expect from some teenager seriously engaged in a which OS or text editor is better holy war.
That's an interesting position. Shouldn't we strive to have a civil discussion despite whatever incivility may have sparked it? Is any discussion irrevocably tainted?
I reserve the right to decide that for myself on a case-by-case basis.
And FWIW, I don't think lecturing someone else about their civility is a civil thing to do.
I don't think the comments were all that unreasonable considering that their subject (Rob Ashton) said:
Person 2: Wrong! Because not all .NET teams are like that.
Now, it just so happens that as general frameworks go, IMO C#/.NET is the signature Les Paul.
Sigh. This kind of arguments is way too common.
FTFY
At least it is tail recursion, though.
I've gotten this on EVERY stack. Not just .net.
I thinks it's more do with age of the project your working on. There is tons critical business applications in .net and java and they don't want to break anything and prefer stability.
If your developing something new, the technology is up for grabs.
More importantly, how would you convince management to allow you to do so?
I have exactly zero solutions to this. If I did I would be rich beyond the dreams of Bezos. But let's not pretend that this isn't the end game of a short-term, low investment, low innovation culture.
Keep in mind that the sort of organizations that use large Cobol systems (e.g. banks) are typically subject to very large amounts of regulation. Their code has to meet all the relevant regulations at all times, plus handle internal business rules.
The laws for all of the regions a large bank works in would likely be tens or hundreds of thousands of pages. There isn't a way to condense that into a small amount of elegant code.
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.
> This is why you can't be a good .NET developer, sooner or later the frustration sets in and you go and do something better. The average ability and desire for something better just keeps on plummetting whilst Microsoft try to chase the brain drain by casting little nuggets of mediocrity at the people left behind scrabbling in the mud.
This was exactly my progression when working .NET in 'Derpy Enterprise Shops'. I don't think it necessarily kept me from becoming a good .NET developer.. But eventually I grew cynical and tired and just gave up on the entire stack. That delta between what we were doing vs could be doing felt like it was too big.
In the end though, its absolutely about culture and Enterprise IT will suffocate you no matter what language.
Where can one find these .NET shops that strive to make use of the latest developments?
We're a marketing startup that uses the .NET stack and it's been a key driver in building a better product faster.
How is that any different to 99% of startups who preach they are "changing the world", but at the base of it, are just a crud app. Only difference is they are using a "hip" language which will probably make your life more difficult than .net
One place I worked, every solution we did had to shove at least 2 of these ingredients into the finished product: 1) .NET, 2) SalesForce, 3) SAP, 4) BizTalk ... frequently it had nothing to do with the merits/needs of what we were tasked to build.
It was simply an equation of having an IT department with these teams, and the department head for each were competing for budget and would inject themselves into the solution or their department would shrink and disappear.
Once "which language will we write this in?" becomes equated to "which team gets this work?" then your company is headed down the bad path. Because now technology choices will be driven by management politics instead of technical aptness.
We are just working on an integration/implementation with one of our systems, and it's quite a drag uninteresting. I don't quite understand the hype behind it, and since our motto (and other people I've spoken to) is "We're just going to move it into Salesforce!" my resentment towards it grows.
It is also unbelievably customizable, with one click plugins that even your grandma can add, and practically anything you can wish for already built for you. It's also extremely familiar to practically every salesperson or management out there.
Basically Salesforce is to CRM what Wordpress is to CMS - the easiest one for non-technical people to use.
The trouble is that the other 25% of the functionally that doesn't fit into the Salesforce mold is hard to come by. Partly due to platform limitions. Mostly because developing on Salesforce is littered with pitfalls and requires intimate knowledge of how the platform works. Most "developers" out there are business analysts/admin who after writing a simple trigger were transitioned into a developer role. I very rarely run into other people with CS background.
Ha ha I actually had to work with it 6 months ago at a late stage startup.. What they needed was a simple apex trigger.. it took 30 min to write on a demo account.
.. but it took us a week to find out we couldn't do it because of the version of SF that we had, and an upgrade would 6x the cost of their monthly licensing cost.
It was a really bizarre dev experience. Really crappy errors!
Business and Sales people love salesforce. It promises instant business gratification via enforcement of best practices through a single unified platform. It also promises to cut down the need for in-house software development, since everything is promised to work out of the box with some point and click configuration tools which the SF admins can easily work on (their slogan is or used to be "no software"). However, as soon as the company realizes that the standard SFDC solutions don't quite meet their business model, that's when the need for custom SF development comes up which is very restrained by APEX/SOQL capabilities and is not cheap. This is often the point where many businesses back track to custom solutions and then build messy integrations that forces the two systems to pass data to each other...
I know what you mean there...lots of DB work and json payloads has been what we are working with. Most of our work is completely custom, so it's been ~interesting~...
It demos well, and you can do some basic things with it. But then you always end up hiring someone to do custom development. So the whole appeal of a point and click platform goes away.
.. This was 6 years ago and I didn't work with it enough to really have an educated opinion. The department that used it thought it was revolutionary technology but honestly most of their devs were rejects/burn outs from the 'more real' engineering teams, to put it mildly.
What we saw in our team (.NET) was that data became siloed and was awkward to use. It was also really challenging to build responsive applications when you had to interact with clunky web services. User experience was absolutely awful the times when we couldn't just send it async.
... that said, if I had the opportunity to architect something like that, I would have rather opted to keep the data elsewhere and just push it to SalesForce when it changes.
I don't blame the company, of course, but I wonder if it isn't sound in terms of business to amortize some of that risk by considering that risky projects let employees self-train and learn new skills that could be of value.
As I survey the mess of JS and transpilers and server-side technologies that have amassed themselves before me, to do the same thing that a Visual Basic Forms app could do 20 years ago, sometime I weep and gnash my teeth a little bit.
My problem with these kinds of Microsoft technology evangelism articles/videos is that it always seems like Microsoft has juuuust gotten their new hotness to work, and is telling the world that it's awesome, and ready for production. Then you go to implement it, and as soon as you leave the perfect world of their demo, it all falls apart, and THEN you find out the docs were written for the beta version, and no longer apply, so you're left guessing at the right invocation signature for the method you need.
My most-recent example of this was their Ruby bindings for Azure blob storage. I wasted DAYS fiddling with the docs, which showed MANY different ways to call the functions, none of which worked for me. I eventually had to have a discussion with one of the people linked to the documentation to get it to work. This sort of thing -- announcing new stuff that isn't ready for prime time -- has happened before (I'm looking at you, EF and WSL), and I expect it will continue to happen, because MS is usually playing catchup with other market hotness.
I haven't used them, but I have no problem assuming that, if I were to go startup a project with the bleeding edge of, say, Erlang, or Node.js, I could find enough documentation to get a working prototype up and running without a lot of hassle.
I guess it goes both ways, though. Once you muscle through Microsoft's bleeding edge, it really feels like you've accomplished something. My Rails app is sending messages, with JSON payloads, to an Azure blob queue, which is getting picked up by my internal Windows service, to be batch processed by a legacy command-line tool, and I'm having the time of my (development) life.
I think the difference is that we use .NET because "it's the right tool for the job," to quote others in the thread. Effectively, it's the only tool for Windows MR development right now. I'd be way more miserable if I was forced to be building bootstrap sites in ASP because middle management said to use it.
They also tend to have lives outside of work, because they get stuff done and go on to other things. Most importantly, they avoid the long drawn out design arguments because that's mostly just bike shedding and they have stuff to do.
[1]http://gigasquidsoftware.com/#/index [2]https://dev.to/vaidehijoshi [3]https://www.youtube.com/watch?v=5hDVftaPQwY
It's a classic catch-22. Self promoters are by definition getting less done, but without that promotion your never going to hear about them, just projects they worked on. Michael Jordan was better in very public ways, the absolute best developer at Verizon, Delta, or the DoD are not spending time competing under spotlights.
PS: I am not a great developer, but I have worked with people that would blow your mind. "We stopped testing his code years ago."
"Don't you blaspheme in here. Don't you blaspheme in here!" /Aretha
And great != "the best". I don't even know how you could define the best at programming. So, I listed some great developers. John Carmack's old code was literally in multiple textbooks I had in grad school, software engineering classes taught Beck's essays. If you ask anyone who's ever work with Sandi, they'll tell you she's one of the best in her domain. All of the listed folks are broadly praised by peers and former coworkers. I'm not sure how else to define great. And, on top of that they are all prolific writers/speakers.
I would also argue that as a matter of tradecraft, writing material that advances the craft and aides in training the next generation of developers is part of what makes one great. Is there someone in the basement of some 3 letter agency that can unroll a loop better than Carmack, sure I'd bet money there is, but being great is about more than that, IMHO.
Now you can argue about what advances trade craft, but having impact is an extrinsic property not an intrinsic one. A lottery winner was lucky, but luck is not some property they have that's going to influence the next coin flip they do. Similarly your measuring impact not intrinsic property's.
Suppose Google chose to spend a billion dollars building a dream team to replace JavaScript with something better. What would the best team they could possibly put together and how much would that resemble the best possible team Blizzard could put together to build Starcraft III. Further out field the department of Energy could possibly put together to simulate fusion reactions. And would anyone make all three lists.
PS: I guess my point is in other fields you can have millions of people apply and get to the top 10 in the field. Programming 'Greats' are a lesser thing selected by more than just skill.
Coming back to whether or not writing well about technical topics indicates ability, I think it's a good proxy. If you can clearly explain how to do a difficult thing well, then you necessarily must be able understand and probably by extension do that thing. Clearly this breaks at some point, but I think it holds true for software development.
However, in my mind that does not mean the top 10 are not out their just that we can't rank the field that way. Which does not mean their is not actually 10 best programmers for any given task. Nor does not mean we should pick some proxy and say these people are the top paid and therefore the top 10 are on this list of 100 top paid programmers or something like that. Because, while ranking people like that might be amusing or fun it's simply not accurate which is my core problem with your line of thinking. It basically says I can't get what I want, so I am going to pretend that what I want is what I can get.
Hm. I'm not sure that effect really depends much on the technology used. Sure, it's a factor and tools that make you feel like they are slowing you down can suck out much of the joy of building things.
But on the other hand: Isn't the true problem that you are building yet another "textbox over database site"? And you'll have to maintain it. This is the part that sounds much less exciting to me than the tech.
Bingo, no matter which language is , bad culture will still suffocate you. Nothing to do with specific programming language / environment.
Good pay, good benefits, easy work. Something to be said about that.
I'd just have to numb myself with opiates or something in order to stay calm, non-confrontational and mediocre.
Maybe it is an age thing.
I've yet to come across someone who has been "happy" with their benefits package. I don't even take advantage of mine because it's such a large chunk for a single person, and yields no incentives - these I would likely consider tangible benefits (aside from the obvious). I could see it being nice if I had a family though, but most people I've spoken to use their significant others benefits package.
The one thing I hope to always have wherever I work is flexible working hours. I very much dislike the stigma of "oh you're not first into the office!". Maybe it's just me though who has ran into this.
It is much harder for me to find a startup that pays as well as a more traditional IT shop would pay me. I can find a 130-140k job in .NET here in South Florida with relative ease. For open source, there are maybe a handful of companies willing to pay that kind of money. In general, these enterprise places will offer very good benefits (vacation/401k w contribution/paid healthcare) and the work is not hard in comparison.
At startups, its just spottier. Last place I worked paid me same as before but didn't contribute towards my healthcare.. That was an extra $1300 / month that had to come out of my paycheck and an expensive lesson.
I'm constantly curious about what other people are working on, or if they are re-writing the same CRUD app over and over.
You can convince people you are a good developer.
It's only a title that other people give you -- there's not an objective, definitive test for it and you can use a number of methods to get that title (actual technical skill, social skills, outright fraud). And of course, if you convince a good number of people, it's much harder for you to lose that title.
I know that sounds cheeky but if you look at interviews and how ridiculous everyone thinks those are, you know we don't have a good technical test to actually prove if anyone is a good developer because the test is so different than actual day-to-day operations we do. If we knew about that test, we'd be using it, and we'd have a hell of lot less "INTERVIEWING IS BROKEN" blog posts.
All of those tests are built on opinions on what a good developer ought to be, and there are tons of variations. Being a good developer and a good computer scientist are two distinct things with some overlapping skills.
The real test is just putting someone in the position but that can be untenable for both sides since they cannot afford to spend the time and money for that sort of accuracy.
I have less knowledge about business value but anything that adds to the company's sustainability or profitability or efficiency (to include non-profit/not-for-profits) is likely adding business value.
This is the main issue, I have been seeing this since enterprise applications were written xBase, Turbo Pascal and C.
In the Enterprise, politics and developers being used as cogs trumps any kind of technology stack one can think of.
From my personal experience producing "enterprise" code for the past 20 years with languages starting at Fortran and ending up with VB.net with all the Python/C/C++/Visual C++/Delphi etc. in the middle, the language/stack choice is orthogonal to the quality of the code base.
You can find wonderful code in VB.net and pure crap in Ruby and vice-versa. This is the company/coder culture which influences the most the end result. Blaming the tools in this case is for me the mark of a lack of experience both in programming and long term software development.
technically true, but in reality there's going to be a correlation between technology stack used and development practices. whether that's Javascript/Swift at super-agile-brogrammer $startup or Java/.NET at Enterprise Corp, Inc. stereotypes exist for a reason.
he's what you can do: evaluate how much you hate an average/mediocre/horrible workflow in said language (for me, I hate anything Javascript, no matter how smart/great the devs are. some people it's the verboseness of Java, etc).
then, go work for/with people you've worked before. i have yet to find another way of evaluating company culture truthfully. (interviews just don't cut it, too much potential to lie.)
That, and, an interview is a handful of hours at most. There's no way to really evaluate a culture in that amount of time, even if nobody is hiding anything. The real problems, the frustrating politics, etc only become apparent after you've been "in it" a while I think.
The one thing I really worry about is being stuck in the MS stack for years and not learning as much as I can (or want to).
I still ~really~ dislike the term "IT" or "IT Dept" - since the majority of the time you are seen as some guy who works on computers or can fix your problem.
I just don't want to become stuck.
It's one thing to be stuck with terrible non-moving technology but .NET is a good technology stack that is progressing in the future nicely. Conceptually you'll be fine.
Usually knowledge learned on side projects are not taken seriously by them, as they weren't on the job. Oh and they love paper (certifications of all sorts).
Algorithms and data-structures always transfer to any stack. Learn the CS mathematical foundations of them.
A good way to avoid being stuck with a certain stack as you put it, is working for a consulting company. It is way easier to jump stacks when switching projects than than trying to convince random HR department of what you actually know.
At my job, they have started trying to convince us that "fungibility" is something that we should aspire to. As though we can't see what that means.
I'm not against good documentation and clean code that makes it easier on the next developer, but this is taking things to an extreme.
Everything sucks if you do it badly.
It's not .NET. It's the mentality of so very many of the shops that pick .NET. The stack and the tooling and the nigh-inevitable process pile-on apply what I feel is more or less a band-pass filter on your output. It's relatively hard to write really stinky code. But it's also relatively hard to write great code. That's not a C# thing--you can write great, brilliant, interesting, smart C#! But doing so at a ".NET shop" strikes me as profoundly unlikely. I have yet to see one, parts of Microsoft aside, that seems to actively reward being smart and curious and expansive in your skill set--and I think a lot of it is because you're a .NET shop, the batteries are included, stay in your lane.
(The same criticisms apply to Java-not-Kotlin-or-Scala shops; fair is fair.)
What's the definition of great code? In all the languages and platforms that I know (C, C++, JavaScript, Python, Java, PHP, C#, etc) if someone wanted me to write "great code" without any other qualifiers I'd pick C# for the job. It's just such a nice well designed static language (except for nullable references) with a reasonably well designed framework that producing great code is pretty easy.
I'm patiently waiting for Microsoft to get .NET on everything but for now it seems like JavaScript is the king of that goal.
What is sort of inconvenient is the dependency management, and that has as a consequence many .NET shops reinventing the wheel.
Another bad thing is the presence of closed source proprietary libraries, meaning they can't be forked and adapted/improved upon. This has somehow changed lately with Microsoft open sourcing some stuff.
Dependency management in .NET is not as good as let's say, Java, Python, Ruby, node.js.
Setting up your project to use Maven, pip, gems or npm respectively is very easy. I have tried nuget, but it is not as nearly as easy to use or reason about as other systems.
For example a month ago Facebook broke .net's built in social login, all installed with NuGet, so I ran a single command and it was fixed.
If you're talking about front end, NuGet can handle it, or the recent versions of VS have a built in task runner that you can easily setup to run Gulp, Grunt, Yarn, Bower, whatever, if you so desire on build/debug/etc.
There are things to hate about the .Net ecosystem (TFS, I'm looking at you), but NuGet ain't one of them.
Can we just ignore this guy now?
Like you can't do composition in C#. You can't blame language for your shitty design!
Toilets ship. Wouldn't want to make me eat what comes out, no matter how much it's ... shipped.
Sometimes I pick PHP as "must run anywhere" is the requirement. The next day I'll pick Swift or Objective-C because it's something Apple related. But .Net is always a possibility.
But yet while nobody really forces me to use a .Net stack I still pick it since the stack is really stable and relatively easy to use (compared to the perpetual change and chaos of a Modern Web Stack for example). Something I've written 4 years ago will still run and compile like yesterday even if I've abandoned it in the mean while.
I've been in those soulless Enterprise shops and it's just what happens to places where people go everyday to watch the clock go six about 28 times per month so they'll see the number on their bank account grow with a predictable number every time.
But somewhere in the world these places exist full of PHP developers or Java developers. The thing with Java or .Net is that some customers have really old stacks and don't want to change anything. It's the new Cobol for some companies while other companies do really cool cross-platform stuff. It can be both. Take care where you take your resumé since the cool jobs are much harder to find since nobody with a living soul wants that kind of enterprise jobs.
Go back to a e.g. Meteor app from a year ago and it will very likely be broken, either by some change to the client js runtime or some change with a newer version of node breaking packages. Unfortunately the changes to the client and security issues tend to force node+package updates.
There's a lot of underappreciated value in long term stability
Are you sure that shouldn't be "fortunately?" I write 90% C# and 10% JS and I would be so happy if there was some structural reason requiring .NET apps to be updated regularly. The number of apps I've run into that are several years past EOL but the client refuses to update them because "well it works and we haven't been hacked yet" is indeed soul crushing after a while.
Updates often cause things to break.
If you want structural changes to force updates, you'd better also have structural changes to force stability of those updates. Otherwise you'll find that you've locked out certain types of customers.
It is terrible when people keep old fridges around. They are less power efficient. They take longer to reach a cold temperature. They are less stylish.
Still, it sure does suck when your fridge breaks unexpectedly and its time to buy a new one. The only difference between the fridge and the software is that the fridge is almost certainly cheaper.
Yes, but it also costs time and energy to create a fridge in the first place. If you are just continuously buying new fridges every few months, you will be wasting a lot of energy, because you didn't fully utilize the energy put into creating the previous fridge.
RoI is the rule in business. You need to get returns out of your investment. If you have to continuously pour more money into the hole to keep it "up to date", that delays your returns. Sometimes to the point of making the entire thing "unprofitable", which is a very bad place for a project to be.
I'll admit--the Microsoft stack is a walled garden. It offers some nice features like Visual Studio integrating with Visual Studio Team Services with its own issue tracker and build server and so on. If Microsoft supports your workflow or integrates with the tooling you like, awesome. If not, well, just wait and hope that it will someday support what you're looking for.
That is the frustrating part of the Microsoft stack. It can be overcome with some architecture decisions at the outset of the project. You don't have to stay in the walled garden.
But the Enterprise is where innovation dies. The Enterprise is where motivated developers' souls are sucked out as they are told "no" constantly.
.NET isn't the problem.
To be fair, they are getting better about that. Git has almost as good support as TFS in Visual Studio these days and MS is even integrating Linux of all things into its latest Windows releases. If that trend continues, MS will eventually be much less of a walled garden.
This.
I wrote a bunch of our (internal, non-internet facing) billing and automation code back in 2003 in C#1(.1?)/.NET 1.1. As we've gradually moved to .NET 4 the code still just works and when we need to it recompiles against newer framework versions with no errors.
Even the assembly of the Data Access Application Block [0] used back then for some of this stuff still works fine, the last time it was recompiled was for .NET 2.0 around 2006, but the IL runs without any trouble on .NET 4.6.
This is a mission critical codebase that doesn't change very often, but when it does it's imperative that it can when necessary rebuild against each major .NET framework update with no dramas.
Stability and confidence is key for us and MS have been very good at that, even when older features are deprecated/obsoleted.
Finally....
...just over two years ago when we were pushing the last of our hosted dedicated server customers to upgrade from Windows 2003 to Windows 2012R2 there were a few folks that were still running websites written in ASP.NET 1.1/.NET 1.1 on 2003. There were probably 40-50 sites and a sprinkling of Classic ASP just to make life interesting. Most customers didn't want to go through the hassle of recompiling and redeploying.
Now whilst there is a .NET 1.1 release you can run on Windows 2012, I really didn't want to be supporting three framework versions (1.1, 2.0/3.5 and 4.x) and CLRs. Having successfully migrated bucket loads of ASP.NET 1.1 sites to 2.0 in the past, from experience, I was fairly confident the 1.1 binaries would run just fine on .NET 2.0 which is the minimum version of .NET that ships in Windows 2012 and the IIS admin bits know about. After a week or so all of these old 1.1 sites were up and running on .NET 2.0 in IIS Classic Pipeline app pools, no recompilation needed and except for one site that used an ancient third party PDF component, all was well in the world.
Now whilst .NET may seem unexciting enterprisey stuff, it's a testament to how much the .NET folks care about stability and backwards compatibility. I'm fairly sure, and I know for sure, I couldn't do these seamless transitions if these codebases were written in PHP (for example).
[0]: https://msdn.microsoft.com/en-us/library/ff649538.aspx
[0]: http://www.loper-os.org/?p=69
Nothing to do with the language/framework, but its adopters.
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.
[1] http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...
Only this month I became aware of RFPs for a JSF one and a ASP.NET MVC 4 one.
Knowing the language grammar and semantics, standard library, good quality third party libraries, database drivers, official build tools, IDE and VIM/Emacs plugins, best practices, main blogs,tooling for native applications, tooling for web applications, backend servers, .... is another matter altogether.
Now multiply this per each language.
I rather constrain myself to JVM/.NET stacks, with a little C++ on the side for pure native stuff. That is already a lot to keep on my head.
Everything else is nice to dabble on rainy weekends, but that is about it.
I'm talking about experienced developers like you, who know what it takes to be productive/get things done.
First you learn grammar and semantics of some new language, then you want to build a product. From your past experience you can tell what's necessary for solution to be successfully created (all the things you mentioned and some more). Make it a list, evaluate, revisit your best choices as you go. Once you find yourself happy in the new environment, you're in a position to more accurately determine which of the tools now is better for the job.
I am an Emacs person regarding Emacs vs VI debate, and got to learn how to use it quite well back in the day (actually XEmacs), but it was only as a workaround for lack of nice IDEs in UNIX.
Nowadays I seldom use it.
EDIT: I guess Omnisharp plugs into Emacs as well.
We have to accept that there is a real human limitation. You cannot be an expert at every technology that exists. If you try, you'll be forever spinning you wheels and never actually build anything.
Why would that be a goal? I'm not saying that mediocre work is a good thing either. A really competent programmer in one language/framework will find out that obtaining a comparable level of competency in another isn't surely going take as much time as one has needed when initially starting. Why? Because programming activities affect programmer's mind and enable deepening of mind's properties such problem solving, organization, logic, attention to detail, creativity, focus etc.
I'm not dismissing problem solving, organization, logic, etc. But you can't dismiss the practical details like what APIs exist, what bugs they have, how do you call them, language features, platform differences, XML configuration file of the week, etc. You can only hold so much of that in your mind at once. And having that is what gives you productivity.
Other stacks follow different programming schools of thought and may result in different approach to a problem.
But the point is that having a bunch of radically different technologies for every task is far from optimal. You simply can't master them all. Right now I made a bunch of technology purchases and I'm looking at Unity development, Tizen development, and Android development all at the same time along with the usual day to day .net stuff and it's way too much. Having a single language/framework would make it a lot easier to produce a result.
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 think you're missing out a lot.