When talking about big tech, we usually mean five specific companies known as the Big Five or GAFAM. Those are Google, Amazon, Facebook (now Meta), Apple, and Microsoft. These companies have shaped the technology world as we know it. They led the five big waves of disruption: personal computing, the internet, mobile, social media (web 2.0), and cloud. When we think of personal computers, we think of Microsoft and Apple. When we think of the internet, we think of Google and Amazon.

Changing APIs is a common problem for library authors. There’s some class or function that you need to change, but you don’t want to break your library’s client code when they upgrade the library. In other words, the change needs to be backward compatible. Sure, there are cases when you’ll have to make breaking changes, but it’s usually better to avoid that. In the case of company-internal packages, when you can modify both the library and the app that consumes it, there are a few nifty patterns to deal with API changes.

We had a ton of stuff go down in the world of C# .NET this year. The big news was all about generative AI, ChatGPT, and Copilot, but the .NET team and the community didn’t take a sabbatical. We had loads of conferences, announcements, new frameworks, and cool tools. There was a fresh C# version release, a new .NET version, and plenty more. Yours truly went over all the 2023 announcements, the most popular conference sessions, the top tool releases, and the most-loved blog posts of the year.

Software companies come in many sizes. There are small startups, medium-sized companies, and huge enterprises. As you might expect, startups are usually lean and fast. Big companies that develop large applications move much more slowly. Those might be systems developed for many years or decades by hundreds of developers. I’m talking about products like the Amazon marketplace, AutoCAD, or any operating system. These products take a very long time to release new features or fix bugs, considering the amount of engineers they employ.

LINQ is one of my favorite features in C#. It just makes the code look nicer. Instead of tedious foreach loops, we got a neat functional syntax that’s easy to write and understand. Well, at least if we’re using the method syntax flavor of LINQ. LINQ is also terrible to debug. We have no way of knowing what goes on inside that query. We can see the input, we can see the output, but that’s about it.

Premature infrastructure is a peculiar behavior pattern that I witnessed in every single tech company I worked for. It is the habit of creating infrastructure code before it is actually needed. The development team is predicting future requirements and preparing ahead of time. That might be preparation for a future feature, extension capabilities that aren’t needed yet, or customization that may or may not be wanted. I believe that creating premature infrastructures is one of the biggest problems in software development.

Do you ever feel like a million tasks are looming over you at any given moment? How about that you can’t concentrate because it feels like you should be doing something more important? I used to have these feelings all the time. I call this “brain clutter”, though I’m sure there are many other names for it. That’s a problem that hurts work productivity more than you might realize. Not to mention your peace of mind.

The more I work in software development, the more I love working with the command line. I notice I’m becoming increasingly productive with it. When dealing with Git, for example, I used to do almost everything in a GUI program, whereas now I use the command line for 90% of the actions. But the command line will make you more productive with everything, not just source control. There are several reasons why it’s so efficient.

We all know the value of debugging. Inspecting the values of variables, seeing the call stack, and moving step-by-step are all features that are priceless for developers. But it’s not always simple to get a debugging session going in real-world scenarios. Sometimes, you can’t get the debugger working. Or you’re starting the program from the command line and want to debug from the very start. Perhaps there’s a crash as soon as the app starts.