A while ago, I had to explain, not for the first time in my career, why using interfaces, having loosely-coupled code, and writing tests (first) is a good idea. Time and again, I find developers, teams and companies resisting certain ideas that have been around for years or even decades. One of the reasons often stated, is novelty. An idea, principle or technology is refused because it is new and who knows what the next thing will be. Better to
A while ago, I had to introduce a developer with little experience in modern .NET development to a project I am leading. I gave the usual talks about the architecture, picked some classes to clarify, explained patterns we use, etc. But I also wrote down some basic principles that are important in the project. When I read them again, I realized they’re some core principles I find very important when coding. I know there are many principles out there to
Here’s a quick tip. If you need to find out if a given date range is covered by another date range, this code does the trick. Let’s say you have an Event class with a Begin and End property and a SearchFilter with a Begin and End property. If you search for events between April 8 and April 12, you would want the following events to be included: April 7 to April 9 April 11 to April 14 April 9
A while ago, a colleague asked how I tracked all the information that’s coming in: Twitter, RSS, Facebook, blogs, podcasts,… It’s easy to drown in all the information if you want. I won’t pretend I have the ultimate strategy, but here’s what I do. Facebook I’m not on Facebook for a variety of reasons (mainly this), but I don’t miss it. So that’s one information-source less to deal with. Twitter This has been my usage of Twitter: Ignore the hype
Please don’t do this: // Create a new customervar customer = new Customer(); // Assign the name customer.Name = name; // Send to server this.customerService.CreateCustomer(customer); Just don’t.
This is a non-technical post to encourage people to, for once, not read a blog or watch a Pluralsight movie, but to write code. I read and watch stuff on coding a lot, but the reason I do is because I want to code. And now and then, you should code. You’ll find you’ll learn more from mucking about, getting stuck, and then finally finishing a feature, than from only learning/reading/watching the theory. I’ve given up in part on going to
Do you find yourself often writing the same pieces of code? I guess we all do: the INotifyPropertyChanged interface and the PropertyChanged method in WPF projects are one example. Unit tests more often than not have the same structure (at least on a per-project basis). Visual Studio’s snippets functionality can speed up your work in this regard. I knew about snippets since some time, but never actually used them. I recently noticed I had to type the same code for
Update: This is an old article that helped us at the time, using a centralized version control system (Subversion). We created our own branching strategy, and in essence, came up with trunk based development before we really knew it already existed. For the record: I would heavily advise against developing your own branching strategy. The issue with making up your own branching strategy is that, like most not-invented-here solutions, you’re probably not going to be smarter than the community. Choosing
This was a blog post I had lying around, waiting to be posted. This post on code smells on the All Your Base Are Belong To Us blog reminded me of it. So here goes. Everyone has coding pet peeves. Pieces of code they can’t resist the urge to change when they see it. Of course, there will be exceptions, or cases where it’s impossible to change the code, or just not worth it. But not that often. Apart from