Greetings,
Apparently it’s about that time, the time that I go ahead and create a blog. I finally got on Facebook a year ago, and I’m at least a year away from convincing myself that Tweeting is worth my time.
Why a blog? What could I have to say that is of any possible use to anyone? We’ll see. Probably not much, but it’s worth a shot. My friends and coworkers have repeatedly said that I should write a book full of the absurd crap that I rant about every day. My high school and college teachers said I was good at writing, but maybe they were just being nice.
Who am I? I’m a software developer, focused primarily on .NET. I’ve been a software engineer, a programmer/analysis, a technical consultant, and an application development consultant.
What’s the purpose? Honestly, it is that I like to hear the sound of my own keyboard. Like most software developers, I have a lot of strong views about software development, what works and what doesn’t, and ways that I’ve learned over the years to make my job easier. If someone can read this and learn a thing or two, great. If someone has an opinion on why I’m wrong, even better.
I change jobs a lot. I’ve worked for small aggressive software companies, large sluggish software companies, and body-shop consulting companies. I’ve done software for mortgage companies, insurance companies, pharmaceutical companies, and food service companies. I’ve seen some stuff that worked, and I’ve seen a lot of what hasn’t. I’ve learned a little from the best places I’ve worked at (GHR Systems, Strohl Systems, etc). I’ve learned FAR more from the worst places I’ve worked at.
I like well-defined process and systems. I like the development process to run like a well-oiled machine. I like simplicity. I like to make everyone’s jobs a little easier. I think it’s a very simple equation to figure out whether a process is too simple (not really solving a problem), or whether it’s too complicated (and costing more time that it saves). I consider design patterns to be good, but I consider Design Patterns to be mere guidelines, not building blocks. I always try to remember that I’m getting paid to build something that works, not something that is cool.
What am I going to write about? Lots of things. Design approaches. Common mistakes and how to avoid them. Source Control, version control, and change management. My general theories on development management.
Will it be any good? Statistically speaking, probably not, but we’ll see. Here we go.