I'm a bad programmer.

I subscribe to a lot of marketing and venture capital related blogs as well as a sprinkling of random friend blogs. But as you also probably guessed, I do subscribe to a number of tech related blogs as well.

The funny thing is that, while I would argue that I'm very into tech (and I love learning new programming languages and tech skills), I don't seem to be digging any of the tech blogs that much. It's not that they aren't written well - they are in fact all MUCH better than my own blog.

And it's not that they aren't useful since I often find the best tech solutions to my own questions in various blogs around the internet.

I think that it's just that I don't care that much about any one given technology or language enough to be able to get too excited about the 'science' of it all. I seem to care a lot more about real-world solutions (ie. things related to real business problems), about building real things, and the how and why it all gets done.

I also think some of that comes from my own experience having worked in gobs of different languages.

I know that most problems *can* be solved in any given language.

Sometimes it's easier for the developer, sometimes it's harder. But it's almost always possible for the developer to solve the problem in a given language.

My lack of interest in the 'science' of tech hurts me in a lot of ways.

For example, I know I could be a much better programmer if I took the time to really learn the internals of how Java compiles code. Or how Ruby stores Hashes in memory. Or how Oracle manages memory. Or how X does Y behind the scenes.

By 'much better' I mean write code that executes with less processing and completes a few milliseconds faster.

And therein lies the problem.

I find it hard to be motivated by such a small detail as a millisecond or two. Especially for the work required on my part to gain that advantage (one of my key traits is that I'm VERY lazy).

Plus the majority of the work I do simply does not need that extra umph.

At least none of it has to date (when I get a project to finally explode onto the scene, perhaps I'll change my tune). So for now, I find good enough to simply be good enough.

I would rather spend my time solving a new business problem, building a new feature or application, or learning a new language than digging deep into the documentation (and source code for the un-documented) for the full 'scientific' understanding of any one language.

And I know that makes me a bad programmer.

But I also like to think that it makes me a pretty good developer and a much more well rounded 'worker'.

Rather than know one or two technologies inside and out, I try to have a general idea of what most technologies can do (and I try to make sure I can actually use them if/when needed).

This way, rather than attempt to fit a given problem into my tech world solving it the best way language 'X' can...I instead try to fit the right world around the problem, solving it the best way I *think* the problem itself should be solved.

It sounds logical to me, but I really think this is a lot different approach than many other programmers take.

Here's four more ways that I think I differ from a lot of other programmers:

1. I don't have a favorite programming language. I have a lot of languages I like for different reasons and would chose to use to solve different problems. This also means I don't ever get into arguments over what the 'best' language is.

2. I care more about getting something to just work than I do about doing it 'right'. My personal philosophy is to get it to work, then worry about making it good, and finally if I have time and a need, make it fast. If I have to write a 'goto' line because it makes the most sense to me based on what I know right now about my problem, I'll do it (of course I try to document my code well so I can quickly pick out the areas that need refactored if/when I go back in down the road).

3. I believe that most problems can be solved with plain English and logic by anyone. I'm happy to sit down with a project manager, a sales person, or whomever and talk through the steps we are trying to accomplish (and the real 'why' behind the steps). My opinion is that, most times, these are the people that are going to be using (and taking responsibility in the front lines) for this stuff when it's done anyway so they probably have the most knowledge about 'how' it should actually be done. Once we have the plain English steps and logic, it's pretty easy for me as a developer to pick a good technology and write up the proper syntax (although admittedly sometimes this is very boring to me once the solution steps have been laid out).

4. I generally don't care about those 40% of a language's features that I'll never (or very rarely) use. I like to know they exist and I'm happy to read through some case studies for them, but until I really need them, I don't want to waste my time trying to figure them out for the sake of figuring them out (unless they really are introducing me to a new way of thinking).

If I stop to think about it, I probably differ in a lot of other ways from the other developers I know (and sometimes hang out with). So much so that I often feel like I'm not really a programmer at all, and certainly I can't be a very good one.

Somehow though, I've managed to spend most of my 'working' days writing code (that most of the 'normal' population wouldn't understand at all). And I've been able to get paid for doing it since the early '90s (stumbling and learning the whole time).

So in the end, I guess I have to consider myself a programmer...even if I know I'm not a very good one!