Desktop application development dominated the software world for many years. However, with the rise of the internet, web applications took over with an incredible pace. When smartphones became popular, mobile applications came to be in huge demand, pushing desktop applications into third place. While the previous statement might be true to startups, there is still an incredible amount of software development happening in desktop applications. Consider programs like Excel, Adobe Photoshop and the Chrome browser.

I’m sure every software engineer with a long career had this dilemma: Should I join a startup or a big corporation? It’s a good question since your professional development, the working conditions, life-work balance, and career development will be very different according to the choice you make. There are many differences between a small company and a big company and it’s important to understand them in order to make the right decision for you.

While trying to explain to a friend what I actually do all day, I came up with this summary of our conversation: This of course not counting coffee, lunch, and snack breaks.

Office politics always sounds kind of negative, right? Like that bad side effect that you have to suffer in your job. Or like a constant obstacle to any good thing that you can achieve. I don’t think I ever heard someone say “I enjoyed the office politics in that place”. Somehow, when a company surpasses a certain amount of employees (say 30), office politics becomes a thing. All of a sudden, instead of every employee in the company having the same goal in mind, the various teams develop individual goals.

One of the most important things in a good project is naming. You can’t deny it – Good names of Modules, Classes, Methods and Variables can make the difference between a code that’s a joy to read and obscure text. Some names are so bad that every time I see them I get a little jolt of annoyance bordering pain. I mean, I worked so hard to build this beautiful piece of code, this piece of art really and it’s now completely ruined by this… Name.

If you’re working on a MEF (Managed Extensibility Framework) application, you’re probably familiar with its ups and down. On the one hand, MEF is a powerful plugin system, that’s a pleasure to work with once you know it well. On the other hand, we all encountered strange failures that originated with MEF. Such failures are a nightmare to debug and identify. There are several reasons why a MEF failure might happen.

I recently had to create a Roslyn Analyzer that envelopes code in a try/catch statement. This reasoning was to prevent loading errors in any exported MEF component . Here’s the analyzer in action: The analyzer does the following: Adds a Diagnostic that finds a MEF ImportingConstructor with content that’s not entirely wrapped in a try/catch statement. Provides a Code Fix to handle the problem. The Code Fix will: Add a try/catch statement around the entire content Add ErrorNotificationLogger.

In part 1 , we saw how C# has evolved from its inception in 2000 to the C# 3.0 release in 2008. C# did not introduce a revolutionary syntax or even revolutionary features. Instead, C# imitated most of its features from C++, Java, Scala, and several other languages. As is the Microsoft way, C# imitated many things but did it better than original. The most outstanding example of that is Generics.

Around the year 2000, Microsoft developed the C# language (led by Anders Hejlsberg ). This language, along with the .NET framework had a significant strategic purpose. Microsoft would create a better language tied to Windows, driving customers to the Windows ecosystem and Microsoft products. Perhaps this was part of the notorious Embrace, extend, and extinguish Microsoft strategy (now in the past). This development came in response to Java, which has gained enormous popularity by then.