Event registrations in C# (and .NET in general) are the most common cause of memory leaks. At least from my experience. In fact, I saw so much memory leaks from events that seeing += in code immediately makes me suspicious.

Initially, C# was born as a strictly typed object-oriented language. It was influenced somewhat by Java and Delphi and was even called a Java imitation by...

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.