Where can one find these .NET shops that strive to make use of the latest developments?
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.
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.
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.
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.
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.
We're a marketing startup that uses the .NET stack and it's been a key driver in building a better product faster.
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.