Introduction

I’ve been developing software for some years and found that simple usually beats complicated and pragmatic choices beat dogmatic ones.

In this blog I want to share some useful pieces of code and ideas.

You’ll never see me use four layers of inheritance and eight projects where an interface and two projects would have done the job.

I like keeping my code clean and clear. Short methods, good naming, good parameters. Some lambdas, but they go if it is not a clear as for/foreach loop or some other alternative.

I’ve seen a developer build a library to call a third party library with eight classes being called between his entry point and that of the third party library call. I know there were eight because I found that he had split some logic between eighth and fourth layers and was ending up in an infinite loop (of course this was production and we were paying for each call to the third party web service). But, boy, was he proud of his abstractions.

I’ve seen people argue for an hour about a for vs a foreach loop, quoting some article or another and then going off writing application that “proved” their choice is better. Neither of them even bothered to consider the IL, or that the application was a website where most of page load times were due to animated gifs.

So that’s what this blog is not about. I hope to show simple solutions to problems I am facing, some will have been asked and answered elsewhere, some, I think not.

And I’m sure I’ll look back on some posts and wonder why I did it that way, but when you’re in the thick of it trying to solve a problem with a deadline you sometimes lose sight of better solutions.

You can reach me at – bryan | @ | bryanhogan|.|net