droz

I began writing C# in 2004. I've been writing it since for business and pleasure. Since Microsoft began adopting a more open source approach, it's been, well, amusing to see the open source culture collide with has been historically a closed system.

"Why isn't there a free, open package that solves hard problem X, it's 2015 after all. How preposterous!" The naivety displayed in these kinds of statements is amusing. There are probably many solutions to hard problem X locked away in proprietary "Microsoft Shop" code bases around the world. It's incredibly daft to assume otherwise. Does this approach lead to a lot of duplicated effort- yes; are there a lot of hacked together half working solutions out there- yes; has the .NET community been ok with this- yes. As is the culture of .NET. It's the fine art of not giving a shit because you're going to get paid anyways.

"Oh these poor .NET bastards, they're just sooo clueless of the world around them; they only know Windows." I'm sure this could be said of just about anyone. All tech stacks have their stars and fry cooks. As with many things, it's a matter of how you want to dedicate your time. Could I spend my time focused on file system design, memory issues, and network architectures. Absolutely! It's great that people enjoy this stuff; I personally don't. It's boring to me same reason I don't enjoy futzing around with Linux. I don't care about how it works; just that it does work. When I write for the .NET/C# stack, my focus is on the business problem. How do I impact the end-user (ie Shannon over in accounting, or little Timmy dipshit in Iowa) in a positive way.

"VS also has this really nasty habit of creating "csproj" and "sln" files. I hate those things." this is like bitching about make files. It's beyond silly. Could it be improved- probably, does it need to be- no. I think make files are a horrible way to do things, do I bitch about it- no. I understand that that is the preferred approach of the environment. Learn what I need to do to make it work and get on with my day. And really, these types of complaints are just childish. You're a professional. Deal with it.

As far as IIS is concerned, we can have a ceremonial burning of the source code one day. That product is beyond useless.

The selling point of C#/.NET isn't it's community- it's its productivity. A company can hire a small team of developers and they can crank out a bunch of code in short order to solve some specific problem. The code will be written the ".NET way" not because that's what's best for performance, but because that's what's best for development. Same thing happens in other technology stacks. Code is written to follow a well followed pattern by its community so that new hires and other developers can quickly suss out what's going on without having to stop and think. It's the same song and dance of using third-party libraries. Bit like a royale with cheese instead of a big-mac. Dress it up different, but the same principles are at play.

Fundamentally, there's going to be some cultural exchange between the traditional .NET crowd and the open source crowd. Both parties stand to learn a lot from one another, and have lots of opportunities to discover overlap. Rather than throwing in the towel and saying .NET is bullshit and used by dullards who solve inconsequential problems is short sighted. Find a place for .NET in your stack, look for opportunities to mix it in with your existing open source technologies. If you can't find a spot for it, then move on to whatever works for you. It's not rocket science.

It's also incredible hyperbole. Makes it difficult to take anything else the author wrote seriously.

Sure the folks at inbox.com will be amused by their choice of product name.

More often than note prestige is something someone is born into rather than earned.

The developer salary costs seem really outlandish. 500k euro for a "top notch developer" and 250k euro for "supporting developers". Where are these estimates coming from?

Well written piece, kudos to the author.

If we are uploading cheques and licenses, why not just have a form with the respective upload sections for each document. Sure, people might get the two backward by accident, but is that error rate really any worse than the false positive rate of the proposed solution.

If you are going to go the machine learning route, then it really only makes sense if you go all the way and do some OCR on the documents to pick out the meaningful information to prepopulate some input screen that would likely appear after submitting those documents.

While the actual case study makes for an interesting read -especially for someone who lives in Colorado - the numerous typo's, spelling errors and grammatical mistakes greatly takes away from the message. Did anyone bother to proofread this document at Calleam Consulting before releasing in back 2008?

Sadly, analog design seems to be becoming a lost art.

What a load of garbage. Nothing like cherry picking a few underprepared individuals to generalize millions of their cohorts.

Author doesn't seem to understand why most people go into software engineering. It's because they are creators not managers.

Employers need to get what motivates their employees and put people in positions that enable those employees to pursue the things that make them happy.

And also recognize that what makes their employee's happy may be completely orthogonal to what makes the employer personally happy.

Passing judgement on those employees that choose to stay in position well into their 40s and 50s is just childish and shows a lack of perspective.

Anyone have experience working at, or with, SpaceX that can shed some light on what it's like to work there?