I've always disagreed with this seemingly popular point of view or opinion that every developer should spend a lot of time outside of his/her working hours blogging or publishing their code on Github or contributing to open source. Those activities can be important but aren't necessarily so and the people doing them aren't inherently more valuable or important than developers who choose not to contribute to open source software or who don't feel the need to make a name for themselves. I also disagree with the notions that developers who are only involved with software development during their 8 working hours a day must be inferior or that they can't be passionate about it or that they'll never be great at it or any of that other crap that you'll sometimes hear people say.

I know some great developers who put their code out there and/or their thoughts by blogging. I also know some bad developers who put their code out there and/or their thoughts by blogging. I know some great developers who aren't involved with software development outside their working hours. I also know some bad developers who aren't involved with software development outside their working hours. There are good and bad developers on both sides of every situation you can come up with.

I think it depends a lot on what people do during their 8 working hours. Can we really say that developers who work 8 hours a day on challenging projects with strong co-workers in teams where knowledge is passed around continuously are missing out on anything if they don't really spend any other time on software development outside of work? That just doesn't make a lot of sense to me. If I look back on my own career so far, I've typically been rather passive outside of working hours in periods where I felt like I was working on cool things, where I was challenged, where I was learning a lot on the job. Conversely, I've always been much more involved with software development outside of work when I was working on things during working hours that I didn't find challenging or interesting or where I wasn't learning anything new. I'm guessing that this holds true for a lot of people, though certainly not all.

Of course, if you're not working on interesting things or continuously learning and improving on the job, it's your own responsibility to make sure that your skills and insights stay up to date. You don't have to put in the effort to do that, but if you don't, you don't really have a reason to complain either when you're not happy with the kind of work that you're doing. Your employer is not responsible for your career and your future, you are.

And if you are working on interesting things and continuously learning and improving on the job, you don't need to pressure yourself to do more outside of your working hours because certain people in the community say you should. A lot of people get involved with blogging and open source with the hope that it'll end up leading to more interesting work in the long term. Who knows, you might just be a step ahead of them already.

First of all, let's take a look at an image that Microsoft uses on its MVP page:

"Independent Experts. Real world Answers."

This is indeed what the MVP program should be about. It is however the exact opposite of what I and many others in Belgium have experienced. Let's cover the words in those 2 sentences a bit more in-depth.

Independent

Most of the .NET MVP's in Belgium work for a handful of companies that happen to be big sponsors of every important Microsoft event in Belgium. Now, could it be possible that the best .NET developers in Belgium all work for these handful of companies? I highly doubt it. I know a lot of great developers in Belgium and none of them work for these companies. And I'm quite sure that none of those people are less valuable or knowledgeable than any of those MVP's. In my experience, there is hardly anything independent about the Belgian .NET MVP's. Most of them got their first MVP award while they were employed by sponsors or 'strategic partners' of Microsoft. Most of them tout the latest and greatest Microsoft technologies, pretty much unquestioned, even if it means contradicting their statements and positions when they were promoting the technology that Microsoft wanted them to promote 3 or 4 years ago. And they're never openly critical of anything Microsoft-related out of fear that it will negatively impact their chances of being renewed as an MVP. They may not work for Microsoft, but they are anything but independent of Microsoft.

Experts

This is a tough one. What makes one an expert? In some fields, people are considered to be experts based on the amount of research they've done. In other fields, people are considered to be experts based on what they've actually done. I don't think I'm going out on a limb here by saying that in the field of software development, what you've done should be more important than what you've researched or read about. In my opinion, an expert in a specific technology should have built at least one, and ideally more than one, non-trivial system using the technology in question and should be able to tell you about mistakes they've made, things you should avoid, and should never use examples that promote bad practices. I rarely hear MVP's talk about things you should avoid. I rarely hear MVP's talk about mistakes they've learned from. I routinely see examples from MVP's that make me cringe. I routinely hear MVP's promote technologies even though they haven't actually built anything impressive with it. I think of a lot of words when I see examples or proposed solutions by MVP's, but the word 'expert' unfortunately isn't one of them. This also applies to the Microsoft Extended Experts Team by the way. I can only question the validity of such a team if it contains people who are listed as experts of a particular technology when I happen to know for a fact that some of those people have never even used the technology they're supposed to be an expert in in a real world project. Let's be honest here: most of the MVP's and the MEET members simply aren't experts. They are people who have a strong interest in a particular (or more) technology and do their best to promote said technology. There's nothing wrong with that at all, but there's a huge difference between that and being an expert in something.

Real world answers

This one cracks me up the most because most of the Belgian MVP's hardly work on real world projects. And when they do, they typically work on "multiple projects" as they like to say it. For anyone who's ever worked on multiple projects at the same time: could you honestly say that your contributions were truly valuable to the end result? Let me put it differently: don't we all know that people generally produce the best results when they don't have to juggle too many things at once and can focus on as few things as possible? You will rarely hear about a Belgian MVP working full time on a non-trivial real-world project. A lot of them get to spend a certain number of paid hours each week on 'community work', which means blogging, writing articles for magazines, creating presentations for events, etc. When they're not working on that, you'll often find them talking on Twitter about pretty much anything but interesting or demanding work. And of course, their employers will occasionally send them to clients for a bit of consulting here or there, or to do a product demo. Unless these guys are putting in 60 to 80 hours a week (which I seriously doubt), I'm having trouble figuring out when exactly they do the kind of interesting work on real world projects that would enable them to provide answers based on real world experience.

It also doesn't help that I've frequently heard rather unflattering stories about these MVP's from people who've worked with them. It's pretty much always the same: they're not invested into the project, they spend too much time 'interacting with the community' and if you let them go near important parts of the code base, bad things usually happen. Now, I'm not the type of person who simply believes everything he hears. In fact, when it comes to matters like these, I generally only believe the stories I hear from people of whom I'm truly sure that they know what they're talking about. And if you've been reading this blog for a while, you'll know I'm rather critical and that I set the bar rather high when it comes to that.

Lastly, my personal working experience with MVP's has been abysmal as well. I once worked for a client where we had to get rid of 2 people because of how bad they performed in real world circumstances. One of them was an MVP at the time, and now works at Microsoft as an Evangelist. The other wasn't an MVP at the time, but has been one for a few years now and is even one of the Regional Directors of this region. A few years later, I had drinks with a manager of the company they both worked for and he bluntly admitted that both of them are useless on real projects but that their MVP status was a huge benefit to the company from a marketing and image perspective. Not exactly the image or branding I'd be looking to put out there, but hey, to each his own.

Why On Earth Did I Write This?

For 2 reasons. I think this whole MVP thing sets a bad example to young and impressionable developers who aren't sure what to focus on to advance their careers. To outsiders, these MVP's sure look like they've got a great thing going and it's easy to see how that could impress people who don't know better. There are already quite a few developers who suck up to these MVP's in the hopes of someday getting to 'that level' as well. I'd much rather see these people put effort into learning about concepts that will last them a long time and building skills that are transferable to multiple technologies instead of sucking up to the wrong people, and trying to network their way to more interesting work because the work that results from that is truly mediocre at best. By all means, try to make a name for yourself by blogging and speaking publicly. But do yourself a favor and stay true to yourself and favor quality over quantity when considering the audience you want to target. Hey, it worked for me

The second reason is because this whole MVP thing is, in my opinion at least, offensive to the many dedicated professionals who give their all at their jobs as they work on real projects that matter, as they try to mentor younger developers in their workplace, as they try to optimize the way they develop software not only for themselves, but for their teammates and their employers or clients. These are your true valuable professionals.

I'm sure I'm gonna get a lot of flak for this post, but honestly, it won't really make any difference to me. The people who'll be offended are people I'd rather not work with anyway. And of course, I feel quite confident that I'll rarely, if ever, have to deal with these people in a professional setting since I'm primarily interested in interesting and demanding work

I hope that this newfound appreciation for Open Source within Microsoft will lead to another huge improvement in collaborative development in the open source .NET community. While Microsoft is now open to accepting contributions from the community, it would be a tremendous step forward if Microsoft would also contribute to other prominent open source .NET projects in the future. In the past, we've seen numerous open source .NET projects become popular and widely used. And unfortunately, Microsoft responded to some of those projects by producing their own libraries and frameworks that basically do the same thing. Except that, for most of those projects, they never quite matched the quality of the open source projects they were inspired by. If only all of that effort spent on duplicating already existing libraries would've been spent on improving what was already there, the entire .NET community would've been better for it.

I'd love to see a Microsoft that works with open source developers and encourages them, instead of trying to duplicate their efforts whenever they feel they need to provide their own library or framework for something that's already covered by a superior open source alternative. These duplicated projects only alienate people that at one point were passionate enough about the .NET platform to work on improving it for free, in their spare time. These are the people that Microsoft needs to cherish and nourish instead of competing with them. Microsoft has shown some interesting signs of better understanding of open source development and collaboration in the past year or so. Here's to hoping they take that critical next step as well.

I like to believe learning should be a hands-on activity as well. Basically, stop consuming, start producing. Don't get me wrong, I do think there is value in reading blog posts (I might be slightly biased on this one), reading books and watching videos, but I find that this value is marginal compared to what you gain by actually doing it.

Hands-on activity (producing) is certainly a very important part of any learning process, but I wouldn't go as far saying that the value of reading books/blogs (consuming) is marginal compared to that of producing. In fact, I believe their value to be pretty equal. I've seen too many people who start producing simple things, and then think they've got a pretty good grasp of the technology they're using and then move on to producing more complex or bigger things without actually knowing enough of the technology they're using to support the more complex or bigger scenarios. The results certainly aren't always pretty and I'm sure each and every one of you has seen this scenario unfold with at least one developer you know. Probably more than that even.

I think in a lot of cases, people start the producing phase perhaps a bit too early and then in their enthusiasm of seeing things working sort of skip the more boring consuming that could've benefitted them a lot. Once you've started producing, you need to keep consuming regularly. A tremendously valuable part of any learning experience is getting feedback and insight from minds that have more experience with a given subject than yours. If you're lucky, you can get this from your coworkers. If you're not that lucky, you'll need to find other sources and books, blogs, videos, user group meetings, etc can be a great way to fill that void. And even if you do get to learn a lot from your coworkers, it never hurts to learn more from the experiences of others outside of your immediate circle, if only because their situations and constraints will differ from yours as well.

The other very important part about consuming is really getting to know the technology you're trying to learn. I've always found it very important to at least get an idea of how things work internally within a technology that I'm using. You certainly don't need to know all of the implementation details but just having an idea of it can really help you avoid a lot of problems once you need to use a technology in a more advanced way than in your initial experiments. Most importantly, it should give you better insights as to whether you're using the technology properly, which unfortunately isn't always the same as getting something working. And as a bonus, you'll probably learn about features you won't immediately need but knowing that they're there can save quite a bit of time and effort later on. Just imagine the improvement of the signal-to-noise ratios that you'd see on mailinglists, forums, and StackOverflow if everyone took the time to get a better grasp of the technologies they're using.

When I start with learning new libraries or frameworks, I usually start off by reading most (and often, all) of the official documentation of the technology before I even get into building something myself. If I want to learn a new programming language I'll look for the most recommended books for that language and buy one (or more, if I wasn't satisfied with the first one). I won't even start using the language until I've gone through the book. Once I feel like I've got a pretty good theoretical grasp of the technology, I start building something with it. I also start looking for good blogs on the technology and subscribe to them. I'll also start following influential people of the technology on Twitter. And I just continuously try to soak up as much knowledge as I can from people who're doing more impressive things with the technology than I am. At first, you might not understand everything they're talking about but after a while, things just start clicking and you're getting a really good grasp of things. None of this is a substitute for learning from producing, but it certainly is an incredible addition to it. And one that makes a world of difference, IMO.

So as I was browsing through a few possible alternatives for my authentication needs, I started thinking about my thought process when evaluating libraries/frameworks to use. I generally base my decision on the following items, listed in order of importance (to me):

• How well does it work for my scenario? If a library satisfies all other items on this list, that certainly doesn't mean it's an automatic lock. How it works and the impact it has on my code is definitely the most important factor.
• Popularity. I've noticed that I let the number of watchers/forks on sites like Github influence my opinion. If a project has many watchers and many forks, odds are high that there's a relatively large group of happy users as well as people involved with the project. It also increases the odds that the project will be around for a while. Of course, inactive Open Source projects often remain available as well but if nobody's working on it, I'm not exactly tempted to take a dependency on it. Log4net is a notable exception to this, obviously. But when a project has a lot of people interested in it, or better yet, contributing to it, it's a good sign that you'll easily get help if needed, it's only going to get better in the long run and that it might get forked should the original developers stop working on it. As the author of an Open Source project that doesn't have a lot of watchers/forks (Agatha), I'm aware that my point of view on this is rather hypocritical but hey, it is what it is.
• Code quality. I don't have the time to do an in-depth review of the code as I'm sure most of us don't do either. But I do like to glance over the code to get a general feel of the quality of the code. I focus mostly on the clarity of the code and also keep an eye open for sloppiness or downright WTF's. I guess the questions I'm mostly trying to answer when doing this are: "is this code I'd like to try to improve or fix if I need to?" and "how easy would it be to debug this when I need to troubleshoot some non-obvious issues?".
• Location of code and issue tracker. A lot of people will probably take issue with this, but I consider it to be a major plus if the project is on Github. Not just because of my personal preference of Github, but because they truly encourage people to collaborate and contribute to projects and they make it very easy to do so. Also, the site is fast! I cringe when I have to look over issues of projects on Codeplex because it's just terribly slow. And the UI doesn't come close to that of Github either. I've heard that Bitbucket is pretty similar to Github, but I've never even looked for projects there. In any case: I want to be able to download the latest version of the code at any time, or of a particular branch if I need to, as easily as possible. I also prefer an issue tracker which is fast, responsive and easy to search. It doesn't have to be Github, but those 2 requirements are important to me.
• License. If it's GPL, I don't use it. Also, I check whether or not a commercial license needs to be purchased when you want to use the library/framework in production. Pay attention to dual-licensed projects because that Open Source license might not apply to commercial/production use!

I'd love to hear your thoughts on this. Did I miss any important factors? I just quickly put this post together so it's likely that I missed some good ones

A lot of people think that I'm anti-Microsoft. And I'm really not. I'm not anti-anything. I am pro-quality. I have high standards because I've seen and experienced high quality solutions elsewhere and when I have to deal with lower quality alternatives to those solutions, I tend to compare them, which is only natural. If Microsoft releases good stuff, I'm more than happy to use it. I even considered creating an Entity Framework training course, similar to my NHibernate training course, because I was hearing many good things about it. But after trying to deal with a certain Entity Framework problem that came up this week in the one project at work that uses Entity Framework, I couldn't help but think "I don't want this mess in my life, no matter how much money I could make with it". I sincerely want to use good Microsoft technology, but too often it just disappoints me. And that in itself, isn't much of a problem since there are plenty of good Open Source alternatives around. What I do consider to be a problem is the reaction that many people have when you're critical of Microsoft technology.

I've often compared it to living in The Matrix. A lot of us are living in a world where they are being pushed into believing something that just isn't true. And some of us at some point get to choose between taking the blue pill or the red pill. The blue pill symbolizes blissful ignorance of illusion, while the red pill symbolizes the sometimes painful truth of reality. A lot of developers in the Microsoft world choose to keep their eyes closed and blindly believe whatever Microsoft tells them to believe. They'll run into a variety of problems with the technologies they've been told to use but a lot of people just accept it for what it is because they don't know any better, or because they're scared of the seemingly harsh world that awaits them should they choose to ignore Microsoft's guidance and venture out into a world that is more chaotic, yet offers more possibilities and flexibility. If you take the red pill, you learn a lot about what's really possible yet you face the added burden of having to deal with the people who've picked the blue pill and even worse, the technology that comes with it. Because that truly is the only bad part about taking the red pill. You'll start taking some things for granted, and when faced with technologies that don't quite match up to what you've recently become used to, you will get frustrated because of it. After all, you know things can be done much better with less friction, yet here you are, dealing with problems that have been solved by other libraries/frameworks already. That is the only sour taste you'll experience after having swallowed the red pill.

The choice between the blue pill or the red pill is one that everyone has to make for themselves. And honestly, I can't be bothered anymore to try to convince people to take the red pill instead of the blue pill. I've learned to adopt a "whatever floats your boat without sinking mine is fine with me" attitude, but sometimes, I can't help but wish for a world were people would try to think just a little bit more for themselves instead of blindly following what a dominant entity is telling them to do or use. Look around, see what other people and communities are doing and honestly ask yourself "are they doing things better than I am?". And if they are, put in the effort to figure out why and how they're doing what they're doing. The worst thing that could possibly happen is a temporarily sour taste, and there are many ways to wash that away.

Of course, that doesn't mean that you have to approach it like that as well. You can indeed learn a lot about a certain technology while preparing for a certification exam, but the whole thing is completely devalued by the incredibly large group of people who do game the system and are only in it to add the certificates to their CV, or to demand a higher salary or rates because they are after all certified professionals. Never mind the fact that many of them never even bother to focus on learning fundamental principles that would benefit their careers as well as increasing the value they bring to clients/employers far more than intimate (temporary) knowledge of a specific technology that's probably going to be replaced by something new in about 4 years anyway. To those of you who've taken exams on WPF: how's that working out for you? Still debugging memory leaks I'm sure

Even though a lot of people know this all too well, they'll still come up with arguments like "but it really helps when clients ask for certificates" or "certificates give me a leg up when clients need to go over tons of CVs". Sorry, but I'm not buying it. Well, I do know that some companies indeed consider certificates a benefit when evaluating candidates but I prefer to look at it from a slightly different angle: those kind of companies often employ people who got their certificates by gaming the system at a much higher rate than companies who don't care about certificates and prefer to focus on real experience and solid knowledge of important fundamentals instead. Simply put: if you choose to work for companies that value certificates, odds are very high that you'll be working with certified idiots.

If you're wondering whether you should invest time in getting certified, I'd advise a different approach. Don't bother with certifications and spend your time and energy on attaining knowledge that will last you far longer, and will even improve your abilities of quickly picking up new technologies. And the way to do that is pretty simple. Work on hobby projects. Experiment with multiple technologies. Study code from established projects and developers. And read books. Lot's of them even! If you don't know which ones, I've got a good list available here and you might notice that the majority of those books are technology-independent. They focus on fundamental principles and common knowledge that you'll be able to reuse no matter what technology you're using now or will end up using later on.

Of course, all of this does take more effort than simply showing up for a 2-day course where everybody gets a meaningless piece of paper or spending a weekend cramming API details that you don't actually need to remember to be productive at your job. But hey, if your goal is to improve your value, and not just your perceived status, it's worth it, right?

Plenty of Silverlight developers were concerned that their investment in the technology would end up being worthless. I never really understood that since I've always believed that good developers focus on skills that are transferable to multiple technologies instead of betting it all on a single technology. Nevertheless, many Silverlight developers were up in arms, but their worries and fears seem to have been calmed by the news that Windows 8 will make extensive use of XAML. Silverlight developers will be able to transfer their XAML skills to building Metro apps and of course, WP7 apps. And there's no reason to assume that Microsoft intends to change its smartphone platform in a way that would diminish the importance of XAML. So, Silverlight developers who were worried that their skills will be worthless don't really have anything to worry about and I'm sure many of them are quite relieved by that. After all, many Silverlight projects will be able to run as native apps on Windows 8 with relatively minor modifications.

Of course, that doesn't quite offer a solution to the thorny little issue about all the Silverlight projects that have been developed because of some of the benefits that Silverlight promised: cross platform and browser-independent availability of the plugin. The promise was that you could develop projects that would be available to users no matter what platform or browser that they were using (believers of this promise would even mention Moonlight, which has never really offered a truly compatible version), and with no deployment-related issues. After all, users only needed to have the Silverlight plugin installed to run your software. And that promise has been broken. Yes, you can migrate your Silverlight projects to Windows 8. Yes, people will be able to keep running existing Silverlight projects as long as they have the upcoming Silverlight 5 runtime installed. But we also already know that the Metro version of IE10 will not run the Silverlight plugin and that running the plugin in the 'desktop' version of IE10 will require users to install it themselves. For enterprise software, that's not much of an issue but you do have to ask yourself: how long are you willing to hang on to a plugin that Microsoft itself is no longer interested in improving in the long run?

The reality of the matter is that your Silverlight products only have a future if you convert them to WinRT so they can run on Metro natively. Which means you've lost the ability to reach users on multiple platforms and devices. The very same technology you picked because of its cross-browser and cross-platform benefits has forced you on a path where in the future, you can only target users on the Windows platform meaning either Windows 8 or WP7. Sure, you can hang on to the fact that the plugin will be available for a few more years, but that also is a limiting choice since an ever increasing number of users will be running iOS and Android, and there's no reason whatsoever to expect the plugin to actually run on those platforms. Hell, WP7 doesn't even have the Silverlight plugin for its browser. My previous employer pretty much bet it all on Silverlight, mostly because they didn't want to deal with HTML/JavaScript, but also because they thought it would eventually be available on all devices. Which essentially means they're stuck with a couple of products that only really have a long-term future on Windows 8 or WP7, and its subsequent versions. Unless of course, current promises about said platforms are broken again. Yet another reason to start taking open standards and technologies that have multiple stakeholders seriously, I suppose.

Whether you love or hate Steve Jobs, Walter Isaacson's biography on the man is well worth reading. I found it to be a fascinating read, and quite funny at times as well. I was expecting it to have a somewhat balanced view on Job's personality, but the author went way beyond that. He doesn't waste many opportunities to point out a negative reaction by Jobs, which is good. There's no glorification of Jobs, just a balanced and honest view. Another important thing that I highly appreciate is that you often get both sides of the story. You get Jobs' recollections and opinions, as well as those of the people who were involved in the many situations that are covered. And again, differences between those recollections are not ignored.

Most things are covered in chronological order, from Steve being put up for adoption, to his time in college, to dropping out of college and going to India, to starting Apple, to getting ousted at Apple and starting Next and buying Pixar, to returning to Apple and returning it to prominence, to him getting cancer and eventually resigning from Apple because of it. There are also parts about his personal life and his family, though the majority of the book covers his successes and failures in his professional life.

For a long time, I thought Steve Jobs was the perfect salesman for what the various teams at Apple were cooking up. I knew he was involved with the product design, but I had no idea he was as involved as he really turned out to be. He was very hands-on in the way he worked with the various product teams, and in many cases he led them based on his vision for what a product should be. But it would be false to say that he originally thought of every successful product Apple has put out, though he apparently had no problems claiming other people's ideas as his own. Stories about his temper and the awful way he treated his employees have been around for a long time, and there are plenty of examples in the book.

What I did find surprising though, is that a lot of people he worked with claim that Jobs pushed them into achieving things they never considered possible and that they loved making such an impact with their work, despite their complaints of his outbursts and the way he treated people. I also found Jobs' take on it interesting. It was his way of making sure that Apple would have as many A players as possible, and to get rid of as many B players (or bozos, as he called them) as possible. He felt that A players only want to work with A players, and that mixing them with B players would reduce their value. You have to admit it's hard to disagree with the results of his approach.

As for his approach to being a CEO in the latter years of his career, the most interesting part to me was that he refused to split his company into divisions where each division had its own Profit & Loss balance. Instead, you just had many teams and the only Profit & Loss balance that they looked at was the company-wide one. Jobs forced them to work together instead of competing with each other (which is the complete opposite of what the young Jobs did in his first stint with Apple) and when people didn't work together, he'd get rid of them. He made sure everyone was on the same page and that there was no confusion about the priorities of the company. He made sure Apple only focused on a few products so they could do them as well as possible, instead of trying to do as much as possible. It's pretty much the exact opposite of how Microsoft is being managed by Ballmer, and that contrast seems to reflect in both companies' success over the last couple of years.

The way he dealt with people, both in his personal as well as his professional life, wasn't as impressive though. It must have been hard to know him personally, and there are 2 stories of his behavior in the book that are downright shameful. In many of the stories of the book, he comes across as a total dick and a cry baby. You can take that literally even: there are countless moments in the book where it's mentioned that Jobs began crying when he didn't get his way. Saying that he had a complex personality is quite the understatement. But he was very good at knowing what people wanted and what they didn't want, even if they didn't know it yet, as he often said. Of course, it's exactly that arrogance that many of the people who don't like Apple products hate. Different strokes for different folks I guess, though I wouldn't be surprised if Jobs turns out to be right in most cases when it comes to most people, or non-techies in particular.

Despite his financial success, I do believe he was driven by building great products, and not just money. Had money been his primary motivation, I think he would've ended up with a lot more of it. The money issues that sometimes come up in the book seem to be more about respect than pure monetary gain, with the exception of one case, when he screwed one of his longtime friends during Apple's initial IPO. In that particular case, the author should've have dug deeper to find out Jobs' motivation. But again, from reading the book it's hard not to believe in Jobs' drive to create things that were truly great. I enjoy many of Apple's products, so in my opinion he's clearly succeeded at that. Though many of the Jobs-haters would probably disagree. Despite what you may think of the man or the products he's introduced, he's had a profound impact on many of the ways in which you and a lot of people you know interact with technology and media. And for that, I am glad he was the man that he was, regardless of his faults.

The biggest problem in the .NET world is that most companies that do .NET development just stick to what Microsoft tells them to use and how to use it. Many .NET developers largely focus on that, because they know all too well that it increases their odds of getting hired. And let's face it: Microsoft has a solution for practically everything. The only problem is that those solutions are rarely the best in what they're trying to solve. But hey, no manager gets fired for going with Microsoft, right?

The result is that there are too many companies and too many developers that focus only on what Microsoft offers. But there's a lot more to software development than what Microsoft offers, or even knows about. There are countless examples of Microsoft being late to whatever technical party is interesting at the time. And when they show up, they certainly don't always make a good impression.

If you're the kind of developer that likes to learn from what other software development communities are doing, odds are high that you're screwed. There is an interesting OSS community within the .NET world, and they frequently produce great solutions, quite often based on succes stories coming from other development communities. The problem is not that .NET developers don't have great solutions available to them. The problem is that the majority of them simply don't know about them only because there hasn't been any Microsoft hype about it, or that the devs who do know about it aren't allowed to use it because their managers are sceptical about it, most likely also because there's no Microsoft backing for the technology or architectural style that is being proposed.

I'm not advocating the avoidance of Microsoft products or solutions. By all means, use Microsoft products if they are indeed the best solution to your problem. But do be aware of the things that are getting attention outside of the Microsoft sphere and use them when it makes more sense to use them. That's the essence of the 'non-typical .NET job' and that's exactly what makes it interesting: using the right tool for the right job.

• The fixed mindset: People who have this, think that we have a certain amount of intelligence and can't do much to change it. To them, a mistake is a failure, a sign that their capabilities aren't up to the task.
• The growth mindset: People who have this believe that they can get better at almost everything, as long as they can invest the necessary time and energy. They see mistakes as an essential precursor to knowledge, the engine of education.

Needless to say, people with a growth mindset turned out to be significantly better at learning from their mistakes. The article also covers a very interesting experiment involving school children. The children were given a test, and half of them were told "You must be smart at this". The other half was told "You must have worked really hard". After that, they could choose between 2 new tests. The first one was more difficult, but came with a mention that the students would learn a lot from them. The other test was similar to the test they had just taken.

And here's where it gets really interesting: of the kids that were praised for their effort instead of their intelligence (I'm going to refer to this group as the effort-kids from now on), 90% of them chose the harder test. Of the kids that were praised for their intelligence (I'm going to refer to this group as the intelligence-kids from now on), the majority chose the test that was similar to the one they had just taken. Presumably, to avoid risking a low score after having already been praised for their intelligence. After the second test, all of the kids took the same third test, which was the hardest one so far. The effort-kids worked hard at figuring out the puzzles, while the intelligence-kids were easily discouraged by their mistakes. After the third test, the kids were given the choice to look at the exams of kids that did better than them, or the exams of kids that did worse. The effort-kids generally wanted to look at the exams of the people who did better. The intelligence-kids mostly picked the exams of those who did worse. The final test had the same difficulty level as the initial test. The effort-kids raised their average score by 30%, whereas the intelligence-kids saw their average score drop by 20%.

I find that kinda stuff fascinating. It also kinda confirms what I've seen from fellow developers ever since I graduated and started working. Every good developer I've met isn't afraid to make mistakes and sees mistakes as learning opportunities. These people routinely challenge themselves by learning something new. They also keep an eye on what other people are doing to get better and they actively try to learn from people they consider to be better than them.

One guy I used to work with was considered to be a great developer a few years ago. Now this was the kind of guy who was not only used to being praised for his 'intelligence', but his self-confidence was largely based on it. He once told me his favorite class in high-school was math because the other people in his class thought it was hard, while it was easy for him. He actually said it like that. When other people started getting more attention for their technical skills and knowledge, he began to move away from coding and started focusing more on writing functional analysis documents. He wasn't bad at it, but it wasn't great either. Now he does a little bit of everything from what I've heard. I'm pretty sure that if his self-confidence wasn't based on the praise he gets, he could've been much better at whatever he wanted to do.

That's just one story but I've seen similar things with other people who seemed to be more interested in what other people thought of what they could do as opposed to actually trying to improve on what they can do on a continuous basis. If they start thinking rather highly of themselves because of the praise they get, they often start thinking it's just not necessary anymore to keep working on improving their skills.

Keep challenging yourself. If you think you're pretty good at what you do (and there's nothing wrong with that), make sure you keep searching for new and better ways to do what you do. And when people praise you for being good at what you do, don't let it get to your head because before you know it, you won't be getting much praise at all anymore.

To the many people who dislike JavaScript, either because of its syntax or its many pitfalls (or both), CoffeeScript is obviously great. They can get in on all the fun and progress that's happening in the JavaScript world, without having to write JavaScript themselves. Purely from a syntactical point of view, it's hard to argue the merits and benefits of the language. I'm fond of Ruby's syntax, so instinctively CoffeeScript looks much more appealing to me than JavaScript. Despite the nice syntax and protection from JavaScript's pitfalls, I still prefer to code in JavaScript.

For starters, if you're doing JavaScript development (whether client-side or server-side), you're likely to use a variety of scripts or libraries written by people other than you. While some libraries are documented very nicely, others aren't. In many cases, I still find the ability to read the source code of a library I'm using to find what I want to know to be a very valuable benefit. I've noticed that I often do this when trying to find out how to do something that I can't find in the documentation, or when I'm troubleshooting something. If you're not familiar with commonly used JavaScript patterns, this becomes harder than it needs to be. Some subtleties might pass you by, or in some cases you might have outright difficulties comprehending the code. Of course, reading JavaScript code from seasoned JavaScript developers can also be a great learning experience about how to properly use the language. Yes, there's a lot of bad JavaScript available, but there's a lot of beautiful JavaScript around as well. I'd say the benefits you can get from reading the code of the libraries you use are directly dependent on your familiarity with JavaScript as a language, as well as its most common used patterns and idioms. If you try to avoid JavaScript by sticking with CoffeeScript, you sort of limit the potential benefits to be had from a tremendously valuable resource.

Another reason is that JavaScript is gradually becoming ubiquitous and that's all the more reason to maintain your familiarity with the language. You're unlikely to build a website without a nice dose of JavaScript, either used directly or through CoffeeScript. Server-side JavaScript usage is on the rise, and the growing popularity of Node.js is only going to increase the usage. True, you can use CoffeeScript with Node.js as well, but keep in mind that you're going to be reading a lot of other people's JavaScript code when you work with Node.js. That's not a slight at Node.js as a platform or development community btw, I very much enjoy working with it and am loving the learning experience. JavaScript is also being used in a few NoSQL databases, and in those cases it's harder to avoid it. Who knows where JavaScript is going to be used in the future? Will you always have the ability to 'compile' your CoffeeScript code to JavaScript in order to take advantage of whatever new environment where it can be used? Maybe you will, maybe you won't. Who knows? What you do know is that the vast majority of documentation and information you're going to find on the internet will be using JavaScript. Again, all the more reasons to become proficient in JavaScript IMO.

Then there's the aspect of debugging and troubleshooting. While you can indeed 'compile' your CoffeeScript code to JavaScript, none of the debuggers available at the moment transform your code back to CoffeeScript at runtime if you're trying to debug something. Ok sure, we all prefer to avoid debugging by writing proper tests but the fact of the matter is this: if something goes wrong, I certainly want to understand the code that I can debug. And even more so, I want that code to be readable and not look like it was generated by a tool (and I'm not talking about a lousy developer). Or if I receive a stacktrace from a tester or (gasp) a user, I would like to be able to look at the code that is listed in the stacktrace without thinking "oh crap, what the hell is going on here? I'm not used to all this JavaScript!!".

Again, I have no issues with CoffeeScript as a language. I like its syntax and the ideas behind it. But for me, that just doesn't outweigh the downsides that I've listed here so I'll be sticking with JavaScript for quite a while longer, me thinks.

We've all heard the most common ways of improving as a developer: read the right books, learn from more experienced people, and above all: practice, practice, practice! And all of that is indeed very important. But i've always felt that being exposed to bad code and having to deal with it can be a tremendously important and valuable learning experience as well. As valuable as repeated practice, reading and following advice from experienced and skilled developers is, none of it will stick with you as long as the pain you feel day in, day out from working with a bad codebase.

When you're working with a bad codebase, it's important to figure out where the pain comes from. Whenever you experience pain while trying to make a change, or while trying to implement a new feature, take a bit of extra time to look for the cause of the pain. Then try to think of a way that would avoid the pain entirely, or at least lessen it. And if you can, implement your solution in the codebase. If you can't, try the approach you thought of in a personal project. If you do this routinely, you're going to learn a lot about what works well and what doesn't. I'd dare say that you'll get a better view on this than people who never have to work with legacy code, since they rarely get exposed to the long term problems caused by the code they write.

This weekend i finally took the plunge. I signed up for a machine at Linode and first got started with my static company website, which is really just a placeholder at the moment until the nice-looking one is done. I knew that getting that up and running with Apache would be easy since it's just static content, but i also wanted to get URL redirection right. I have 2 domains for it: thatextramile.be and thatextramile.net. I wanted thatextramile.be to be the domain that hosts the website, and i wanted to make sure that all requests to www.thatextramile.be, www.thatextramile.net and thatextramile.net received a 301 redirect to thatextramile.be. The best way to do this is to use the mod_rewrite module of Apache, so i started reading its documentation and got that working pretty quickly. To do this, i also finally had to learn how to properly configure DNS records but that too turned out to be pretty easy.

After that i wanted to get a copy of my blog working on my new server, while still keeping DNS records pointed at the old one. So i started installing/configuring PHP and MySQL, imported a dump of my blog's MySQL Database and copied the WordPress installation from the old server to the new one. I modified my laptop's /etc/hosts file so it would resolve all requests to davybrion.com to the IP of my new server so i could properly test it. I wasted a bit of time here because of some file permissions, but once i noticed that everything just worked. And pretty fast too. I also made sure that all requests to www.davybrion.com were properly redirected to davybrion.com because Google tends to punish you in their rankings when they think you have 'duplicate content' and i don't want to reduce the traffic that Google sends my way.

At this point i was still waiting for Dreamhost to transfer the registration of my domain to DNSimple, which for whatever reason was taking a lot longer than the transfer of my thatextramile.net domain which was taken care of in just a few hours. While i was waiting i decided to compare the load times of requests to the blog on the new server with the time it took on the old server. I used YSlow and Google's Page Speed Chrome plugin for this. I was kinda hoping to get raw figures from those tools, but instead they both gave me a shitload of tips on how to improve the performance of the site. It certainly already felt faster than the previous server, but a big factor in that was probably the fact that the old server was located in California while the new one is located in the UK. But those tips got me to look into minification and combining of JavaScript and CSS files and putting it on a CDN with good future date expiration headers. That got me looking into the W3 Total Cache plugin for WordPress, in combination with using Amazon's CloudFront for static content. I haven't succeeded yet in getting every bit of JavaScript combined in one file because some plugins don't really play nice with the W3 Total Cache plugin, but in general most page-loads should cause far fewer HTTP requests and they should be dealt with more quickly than previously because of CloudFront.

So once all of that was working, i just wanted to 'turn the switch' and start using the new server for all requests, but the domain transfer still wasn't done. It then hit me that i could just change the DNS settings on the current registrar to point to the new server so i modified the A records for davybrion.com and www.davybrion.com to point to the IP of my new server. And that was all there was to it. Well, i also spent a bit of time in hardening the server but that didn't take long since i only have 2 publicly available services. Is it going to be totally secure? Of course not, but the number of ways to get in are limited enough.

So to recap: i did a lot of reading to understand what i needed to do, and i'm pretty happy with the results. I learned a lot of new things, finally moved everything to a new server that i have full control over, no longer have to deal with the shitty support from my previous host, and am paying the exact same monthly amount as i used to. Not to mention the not so unimportant part about the blog feeling a lot faster (though i'm not sure how fast it'll feel for non-european visitors). Sure, it could go down at any moment and it'll be up to me to fix it. At that point i'll read up on whatever i need to read up on and then just try to improve the situation.

The whole thing took me about 8 hours. Pretty sure it would've taken me longer if i hadn't taken my time on the reading parts because i would've spent more time troubleshooting the inevitable mistakes that i would've made.

Note: DNS changes are still propagating, so if you're reading this from a feed reader, the site may not work correctly yet for you. If you do happen to notice a problem, i'd appreciate it if you mailed me the details, preferably including the IP address that 'davybrion.com' resolves to on your machine and if possible, your local time + timezone info so i can look for matching elements in my logs

People develop frameworks so other people don't have to deal with certain details all the time. People use frameworks so they can focus on what matters to what they're trying to do, without having to focus on lower-level stuff that's not really relevant to them. I mean, that sounds great, right? Just use the right framework to do what you want to do and you instantly become more productive! Even if you picked a good framework to use (and we all know there are plenty of bad/horrible ones to go around), you still need to know what the framework is doing. Abstraction purely for the sake of not having to know what's going on is hardly ever a good thing when it comes to software development. Does that mean you have to know every single detail? Of course not, but you should be aware of the things that might end up hurting you.

In software development, nothing is free and when something suddenly becomes easy due to a framework, you ought to figure out why it becomes easier and how that is achieved. If you get the answer to those 2 questions, you're much more likely to use the framework more responsibly instead of following blind faith or not caring about things that you simply can not just ignore. Like it or not, memory management matters. The cost of complex database operations (leaving in the middle whether you're using an RDBMS or a NoSQL solution) or the frequency of them matters. Bandwidth matters. Remote calls matter.

And there's a lot more to it than possible performance issues. Unwise usage of frameworks can also have a detrimental effect on the maintainability of your code. What might look like an improvement at first could very well lead to serious inflexibility and/or fragility in the long run.

Simply put: a lot of the things that frameworks try to hide under the carpet matter. Every benefit you get from them has a potential cost. If you want to keep enjoying those benefits, you better learn how to avoid the costs.

I used to think it was more interesting to focus on one platform/language and really strive to know it thoroughly, but i couldn't disagree more with that nowadays. I've noticed that there are quite a few advantages to learning new languages and exposing yourself to new communities, approaches and ideas. And i believe they far outweigh the benefits of sticking to just one platform/language. There are 5 advantages in particular that i'd like to discuss in more detail.

It expands your horizons

There's more to becoming productive with a new language than merely learning the syntax of the language. You're going to learn about new tricks, new libraries and new ways of solving problems that are common in the community of whatever it is that you're learning. You're basically trying to soak up knowledge that is common to others, but new to you. Depending on what you already know, there might be a lot of new stuff to learn or it might just be small tidbits here and there. If you already know a dynamic class-based language, learning another one might not expose you to a lot of new stuff. But if you're used to static class-based languages, learning a dynamic class-based language is going to be quite an interesting experience. Try to mix paradigms to get the most out of this. It'll start to influence the way you think about problems and how you can solve them.

It makes it easier to learn new things

Practice makes perfect, right? If you're routinely trying to learn new things, the very act of learning new things actually becomes easier. A lot of people have problems learning things that conflict or contradict with what they already know. The first time you learn a new language based on a paradigm that you don't quite understand yet, it might take a while to grasp it because you're likely having difficulties thinking about things outside of the structure and rules that you're used to. It'll be easier the second time, because you're already more comfortable with letting go of what you already know and not restricting the way you think about things or try to comprehend them. And it'll keep on getting easier and easier. This obviously applies to more than just programming languages.

It continuously refreshes your love of programming

This one probably depends from person to person, but when i was still just a C# developer i routinely got into stretches of time where i didn't really have fun writing code. During those stretches, writing code was just a job, and no longer something that i once considered a joy and a hobby. Those stretches could last a couple of weeks, sometimes even a month or two. Since i started learning more languages, i haven't really hit a stretch like that anymore. It remains fun, interesting and challenging because you just keep on learning new things and you keep on improving continuously.

It decreases your reliance on certain tools and introduces you to new ones

2 years ago, i couldn't imagine writing code without a strong IDE to back me up. I was so dependent on Visual Studio's (and Resharper's) Intellisense, code completion, code navigation and strong debugging features that i just couldn't believe i could be as productive without those things. Nowadays, i really just prefer to code in a strong text-editor (TextMate was my favorite, but i recently switched to Sublime Text 2) with a terminal window to run my tests. I avoid debuggers by working in small steps, with small, focused tests which also make it (relatively) easy to isolate bugs and fix them. I actually don't mind 'poor man's debugging' (putting log statements in certain parts of your code to find out where things go wrong) anymore because i'm starting to think it can often be quicker than relying on your IDE's debugger. I recently even joked that they call it poor man's debugging because it's used by people who can't afford to waste time waiting for an IDE and its debugger . Another benefit is that you'll have to get comfortable with the command line and perhaps even different operating systems. If you want to get into Ruby or Node, you're better off installing a Linux distro (or run on OS X if you happen to have a Mac) and experiment with the language/platform on that instead of trying to get things working on Windows. Getting comfortable with a *NIX shell and its tools is something that you're probably going to be able to use for a long time to come so there's no reason to shy away from it.

It makes you less emotionally attached to a language/platform

People who only work with one language/platform often have an emotional attachment to it. If you're emotionally attached, it's not always easy to remain rational during discussions or when the future of your language/platform is being threatened. If you know more than one language/platform, you know that your skills are transferable. You know that you can be a good developer no matter what you have to work with. You know that you really don't have anything to fear about how things will evolve. You just know that you can deal with it. Easily even.

A lot of people love to talk the talk when it comes to writing clean code. They'll stress their dedication to it, in some cases even wearing Uncle Bob's green band while coding so they'll never lose sight of what's incredibly important to them: writing clean code. Unfortunately, i've noticed on numerous occasions that many of these people don't always put as much emphasis on what the code is doing compared to how it looks. Sometimes they don't really bother to learn what their ORM is doing behind the scenes. Or they'll prefer to use something like Automapper to map entities to DTO's even though it is woefully inefficient compared to simply retrieving projected data. They don't always think about the cost of multiple remote calls or sending way too much data over the wire. And when they're not perfecting the art of writing bowling games over and over again, they just might hit the database in loop.

Clean code is not necessarily great code, nor is great code necessarily clean code. To me, great code is code that works great, performs great, is easy to understand and easy to change. In that order. I know all too well how important it is to easily understand code when you first read it, and to be able to easily and safely make changes to it. But no matter how easy it is to read or change, if it's not doing what it should be doing (including covering all the corner cases) or if it's taking more than its fair share of time to do it, it's not good code. Sure, it might be clean, but it's not great, is it?

That doesn't mean that you should indulge in premature optimization. Unless you have Neo-like skills in this coding Matrix, you're unlikely to be right in even a quarter of all scenarios that you want to optimize prematurely. There are however a few guidelines which will help you avoid most common performance problems. Most other situations are better left ignored until proven by a profiler to be a bottleneck. But you should at least think about what the code is actually doing and whether or not any downsides to that are worth the cleanliness. Don't hesitate to go with the slightly less clean looking code if that code makes more sense from a correctness and performance point of view.

By all means, strive to write clean code. But think twice before you sacrifice its ability to be great.

The original post was a rather silly rant where the author vented his frustration with the community he had previously been a part of. And yes, some of you are currently thinking "umm Davy, didn't you do the exact same thing last year?". I sure did, and i know now how stupid it was (personal growth for the win, amirite?). I too was very frustrated with the state of the .NET community, found something that i thought was better and took a few shots at the .NET community, like some other people who've moved to a different community.

The thing is though: why even bother? Sure, sometimes the urge to tell someone (or a group of people) off is hard to resist. But doing so rarely benefits you, and when it does, it's most likely when it's targeted to one person who might need to be confronted with something. If you tell off a group of people, what good can you possibly expect to come out of it? You can't expect them to suddenly agree with your point of view, even if some of them might do so. The majority of them will just think you're a dick and will be even less inclined to listen to what you have to say in the future. So what exactly did you accomplish? Apart from getting a bunch of people to think less of you, there is absolutely nothing to get out of it. Also, if you plan on becoming a vocal member of your new community, you might want to keep in mind that some of the people in that new community will take notice of your childish rant and some of them will expect you to do the same thing to them once you're ready to move to yet another community a few years down the line. You won't just look like a dick, you're also setting yourself up for negative future expectations that some people will have of you. Really, why even bother writing such posts? If you need to vent, at least try to do it in a constructive manner and in a respectful tone instead of acting like a spurned lover or a kid that didn't get his way.

As for the people who reacted defensively to it, again i ask: why even bother? Why get all worked up about something that was written by someone who doesn't even want to be a part of your community anymore? Why even get angry or frustrated about someone making a blanket statement that wasn't even directed at you personally? Why would you extend the attention that it's going to get by going on and on about it on Twitter? That too, is off-putting and a waste of time and energy. Not just yours, but everyone else's who has to filter through the noise. And what exactly are you arguing about? You're arguing about something that is inherently subjective. Do you get into heated arguments about music or movies as well? You're getting all worked up about other people's preferences, which doesn't really improve your life or situation in any way at all. On the contrary, your whining about it might just result in people not wanting to listen to you anymore either. I unfollowed a couple of people on Twitter because i didn't see the point in reading the same bitching in my timeline for a couple of days in a row. If you really need to get it off your chest, write a coherent post about it, publish it and make your statement once and then move on to something more interesting, like, having fun building working software.

Different strokes for different folks, people. Focus on the things you find interesting and have fun with it. Enjoy building things and try to improve by learning whatever you think will make you a better developer. Consider sharing what you learn with others if you have time for it. But please, let's quit bitching about other development communities because there really is nothing good that can come out of it.

I still do .NET professionally, and i expect to keep working with it for a few more years because there's just not that much work around here (Belgium) with alternative technologies. And the work that is there most often pays a lot less than your typical .NET job. It shouldn't only be about money, but it does start to matter increasingly once you're no longer in your middle-twenties. So what do you do if you're passionate about development, but aren't quite as passionate anymore about the technical environment you use most often? I started learning Ruby last year and it was an eye-opening experience for me on multiple levels. I love it as a language, and i like a lot of the stuff that is happening in and coming out of the Ruby community. Is it all perfect on that side of the fence? Of course not, nothing is. But it's worth learning, if only because it will expand your mind and your views on software development.

For the past 6 months, i've become increasingly fond of JavaScript and while i don't like it nearly as much as Ruby (still my favorite language), i am very intrigued by the fact that is becoming increasingly relevant on both the client and the server. I want to dive deeply in the world of Node.JS, but i also want to learn more about Backbone.JS and Knockout.JS. I want to explore the world of automated testing for both client-side and server-side JavaScript. I probably should look into CoffeeScript as well, but i'd like to become proficient in JavaScript first before i switch to something that compiles to JavaScript, if only because you're likely going to be reading a lot of JavaScript code anyway for the next couple of years.

Will i still like JavaScript as much 6 months or a year from now, or will i be trying to learn something else by then? Who knows, and really, who cares? What matters to me is that i keep learning new things this way, which keeps things interesting for me. Some of the stuff i'll learn won't be usable to me at all in my daytime .NET coding, but some stuff will. You can never quite tell in advance, just like you can't really know in advance whether it's a good investment to jump into the latest and greatest thing in the .NET world. The only thing that really matters is that you keep enjoying the journey, no matter which technology or language or platforms you get that enjoyment from.

Surely, if the core audience of one of their most-touted technologies of the past years started to doubt the future of their platform so openly, a response to calm down the fears would have to be forthcoming, no? The only Microsoft employee to respond was Pete Brown, and i thought it was quite telling:

You all saw a very small technology demo of Windows 8, and a brief press release. We're all being quiet right now because we can't comment on this. It's not because we don't care, aren't listening, have given up, or are agreeing or disagreeing with you on something. All I can say for now is to please wait until September. If we say more before then, that will be great, but there are no promises (and I'm not aware of any plans) to say more right now. I'm very sorry that there's nothing else to share at the moment. I know that answer is terrible, but it's all that we can say right now. Seriously.

Followed by:

Guys, I've been pretty clear that my hands are tied here, so don't read anything more into my lack of comments than that. We simply aren't allowed to say anything about this. It's not that we have nothing to say. It's not that we don't care. It's not that I personally don't care, because I do, a lot.

And finally:

This whole thing has blown way out of proportion. Base your information on our primary sources (like our press release), not on third party speculation. That's not to minimize how everyone feels, but keep in mind that Windows 8 itself is still a ways off from retail, and even much further away from internal IT adoption. The 8 weeks until //build/ is a pretty small amount of time to wait in comparison. Take some vacation time this summer, and look forward to the //build/ conference. Stop speculating based on just a small demo of some very cool new technology. Tell your management to do the same: if they're basing your project work for the next X years on the results of a quick demo for an unreleased operating system, then they are doing you and your company a real disservice.

If i were still a Silverlight developer, i'd find the final sentence quite insulting. If anything, Microsoft is doing a sizable portion of their customers a disservice by being so unclear about the future of one of their technologies. This certainly isn't the first storm to come up about Silverlight's future, and every time people have openly questioned the future of the platform Microsoft has responded rather softly. There's never been a convincing and strong "we are fully committed to making Silverlight a smart choice for the future" kind of response. And this time, no response at all. Just silence. Deafening silence even, because of Pete's remark that they are not even allowed to talk about it. Once again, the Silverlight community is screaming for a real response and they're being ignored. They're being told to wait until September.

Obviously, i don't know what Microsoft is planning for Silverlight, but i really have difficulties understanding how any company could still trust it as a viable technological choice. First the mixed messages, then the clear favoritism Microsoft is showing towards HTML5 and JavaScript (which, IMO, is justified but that's another topic), and now the unwillingness to stand up for one of their products that is being doubted so openly, for the first time by its very users who only want assurance of Microsoft that their investments in the technology haven't been a total waste. I took a lot of flack from the Silverlight community when i scored Silverlight so low in the 'strategic' department in my post where i detailed how we came to the conclusion to go with HTML(5) instead of Silverlight but this recent PR fiasco kind of validates that score IMO.

However, Microsoft certainly isn't the only one to blame here. If you read the thread i linked to, you'll see some reactions from people who've pretty much put all of their eggs in the Silverlight basket and are now reacting angrily towards Microsoft. If any of those people are reading this, allow me to quote myself from 2 posts that i wrote over 6 months ago:

If however, your product is supposed to become the basis of your long-term success, then the choice of Silverlight over HTML/CSS/JavaScript is short-sighted and ultimately flawed for a number of reasons. The first of which is that Silverlight is a proprietary technology in the worst possible way. Its future will be determined by a single company who naturally hold their own best interest at heart, and not yours. As long as it makes sense for them to keep improving Silverlight, they will and you can benefit from that. As soon as it no longer makes sense for them, the technology will become increasingly irrelevant. Obviously, that is a risk that you face with any kind of technology. Sticking with open standards and open source software might very well result in the same outcome but there is one tremendously important difference here: with Silverlight, you have no migration path.

That quote was from 'Keep Your Eyes On The Road', written in September 2010. And the next quote is from 'Developers Shouldn't Specialize', written in October 2010:

There's also another factor to keep in mind, which is more important than you might realize. If you specialize in technology from commercial vendors, you need to keep the market forces in mind that could influence the vendor. Those market forces might be (or seem) irrelevant to you, but the vendor will not let that influence its decisions and strategies if the vendor itself is competing with other companies on a much larger level than your company or your clients are. And when a vendor changes tactics due to market forces, the technology you've chosen to specialize in might be on the way out, or it might no longer be the hot new thing that you can capitalize on. And that is where one of the biggest dangers in specialization lies. If you're specialized in a specific technology, you're personally invested in it. Your current standard of life, your livelihood, depends largely on that specific technology. Sure, you can move on to something else but you will have to get used to less than you're used to, probably both in money and stature for a while. Realistically speaking, odds are high that you are emotionally attached to this technology because of this. When you are confronted with bad news regarding the technology's future, you're likely to exhibit classic denial symptoms. The recent news about the Silverlight strategy shift and specifically the reactions to it, is a beautiful example of this.

Anyone who's upset at Microsoft about this has only himself to blame. You've put yourself in this position, because the writing has been on the wall for a while now.