As a few of you know, I was briefly employed from the tail end of February until late last Thursday, when I got downsized. It was an excellent group to work with and I plan to stay in contact with those guys. While I can’t get into too many of the details, it wasn’t due to performance or anything like that. It’s just that the sort of clients I work with sometimes have things change out from under them and things go in different directions. It stinks, but life is full of surprises. If I wanted a boring, perfectly safe job, I’d get that tomorrow (and some HR algorithm would probably reject me, but let’s just go with the optimistic case for now). That’s not what I do though. I’ll go back and work for them again in a heartbeat if the opportunity presents itself.

As software developers, one of the main things we are tasked with is the automation of business processes. Typically, we’re given a task to do, with much of (if not all of) the process laid out and told to get it done. As a result of this sort of thinking, it tends to be our default mindset to either attempt to automate everything, or to avoid automating anything in our own workflows. The decision of when to automate is something a lot of developers struggle with, as it’s very easy to either put up with irritating, repetitive processes, or to get lost in the weeds trying to automate something that really isn’t worth bothering with.

I know this is a bit outside the normal content for this blog, but since I get asked frequently, I figured I would share my method. It usually takes me an hour or two in total to build a blog post, although some of the longer ones might take as much as three hours. I do sometimes get interrupted, but for the most part, I’m able to write the whole thing without too many problems. I’ve refined the method over time to help improve my speed as well.

Object-relational mappers (hereafter called ORMs) are used to provide a way for one to map an object in an object-oriented language to a table or set of tables in a (usually) relational database. On the Microsoft stack, they’ve become so popular as to be nearly ubiquitous. They do have their detractors, including people that have developed their own, such as Rob Conery, who developed TWO ORMs (Massive and Subsonic). That said, they do often make the earlier phases of a project much easier, by allowing developers to abstract away the pain of relational data access. This is frequently helpful in the early phases of a project because developers are moving quickly and breaking things while trying to quickly iterate over a design. That said, I find that the way ORMs are frequently used is often rather unhelpful as a project matures (and possibly rather unhelpful in the early phases as well).