When using AutoMapper to map objects from one type to another in your code you need to implement something like below:

var someMappedDto = Mapper.Map<SomeModel, SomeDto>(someModelInstance);

If you look at the code there is a bit of noise here in my opinion. So what do I mean by noise? I consider anything in my code that gets in my way or does not provide me direct feedback as noise.

In the line above I consider the following noise:

1. Mapper.Map – I do not like this because having Mapper.Map sprinkled all over my code base just means that my code has too much knowledge of the actually mapping library we use, this is noise.  Hey, it was for this basic concept that the Common Service Locator was created to help prevent
2. Having to provide both the source type AND the destination type – The source type should be able to be derived from the source object instance (in cases where you do not want to use the mapper for some child type of the source type).  I concede that you do need to provide the destination type other wise we would have no clue what you want in the end
3. Having to provide the source type instance in the constructor. 

In order to reduce the noise, and make for cleaner code I would like to see something like

var someMappedDto = someModelInstance.Map<SomeDto>();

This feels nit-picky but it is something to keep in mind. Especially when using a bunch of generics. C# Extensions are your friend.

I've seen this way too much as well. Jeff Wilcox is right, please group methods by functionality and not visibility.

I found the error of my ways in the Clean Code book by Uncle Bob Martin. It is my new bible these days.

I’ve stated previously that reading software development books is a good way of investing in your skills and your career. But which ones should you read? And in what order should they be read? I’ve compiled a list of books that i think can truly increase your skills substantially. I’ve put them in the order in which i believe they will have the most effect, and grouped them in 3 ’stages’. I primarily have young developers who are just getting started as professional developers in mind with this list, but it should be just as useful to developers who’ve been around for a while and simply want to improve.

I've at least browsed and considered buying most of these books. After reading Clean Code, which straightened me out a good bit, I should reconsider reading the rest.

I have written far too many null checks in my life. Why do we have even null values? They only seem to provoke a NullReferenceException in our code after all. F# for example has the option type with the value None which is semantically the same as null without being null which makes it impossible to access invalid values by accident. It is of course possible to create null values in F# but it is not the most natural thing in a functional programming language.

Alois Kraus complains about null checks and has some code ideas to get around it. Using an extension method with a lambda doesn't feel like a good solution though.

Ultimately, he wants a language change to have a reference type be suffixed by ? to mean "if not null then run this method or property." That might could work.

Another idea I saw in a language...I forget in which but I believe it was related to me reading up on Google's Go language. Anyways, the idea is that nothing can be null unless you explicitly mark it as nullable. Which means, Nullable Types work make since for reference types and a reference typed variable could never be set to null.

This would definitely be more explicit (ding) and it would confirm to the Clean Code idea of never setting anything to null.

There has been an increase in interest in Software Katas of late. What is all this buzz about, and why might it be important?

GOOD QUESTION.

It's a sound idea. I just wish there was a better name. It just sounds goofy.

Testable Java
It's often hard to retrofit unit tests in code that wasn't designed to be testable. In this paper, Michael Feathers describes a simple rule that you can use during development to assess the testability of your Java code.

Michael Feathers wrote a FANTASTIC rule to remember when writing code to make it easy to test. His example case is Java but the rules can easily be adapted to C#. I need to train myself to remember this.

I should also get around to reading the his book that I bought.

In the previous post of the Introduction to the Reactive Framework series, we covered how to create new IObservable<T> instances, either from scratch or from existing sequences.  What this allowed us to do was turn an operation which was previously interactive, such as iterating over a collection, to a reactive, where I could have multiple listeners reacting to the same collection concurrently.  This has nice implications for allowing us to scale our application in interesting ways.  This time, let’s take another angle on making asynchronous programming easier.

Just more IObservable goodness. Though, I'm not sure I like the way the ending LINQ statement looks.

I guess a more Clean Code way would be to hide some of the subqueries behind methods.

Agile Development community, we use the term “technical debt” to refer to this problem.  When you don’t keep your code clean, you incur debt, and as in other areas of life debt reduces your options – it can become crippling over time...

Michael Feathers compares technical debt to credit card debt. I think it's very apt.

Maybe I should try to read his _Working Effectively with Legacy Code_ book another shot. I felt it was too beginner for me. I should just read it. You can always get something new from rereading the basics.