Constantly learning is important. Lots of disciplines today change at an extremely fast pace. Software is definitely one of those fields. As we learn new things, we try to integrate them into our existing mental frameworks. We think of different areas where we can apply this new knowledge, or if it can be used to simplify any existing solutions. I for one am constantly trying out new frameworks or languages by thinking of apps I can write with them :)

There is a caveat here though, particularly with newer programmers. Right after learning a new pattern, we have the propensity to use it more than we should. We force it to fit our problems, usually by throwing more patterns in the mix. The code ends up being far too complex for what it's supposed to be doing, and it's much harder to follow what's actually going on. In short, we end up with more complexity and less flexibility. That sounds like what we were trying to avoid in the first place.

Programmers also tend to get emotional and invested in their solutions. Admitting that we took the wrong path is hard to do. Software is the kind of thing that doesn't really have just one answer; we can solve our problems with just about any language or technique. Some are obviously better for certain problems than others, but just about any of them can be *made* to work. This brings me to a quote:

xml is like violence. If a little doesn't work, just use more of it.

I've got more quotes about xml, but I'll save those for another day :)

We all have our own opinions on what kinds of software or tools are useful, and many of us have very strong opinions on these matters. My opinions here tend to change on a daily basis :) But even though we don't like to admit it to ourselves, virtually every approach has its own tradeoffs. In fact, I'd go so far as to say that most of programming is just a series of tradeoffs.

The important thing is to use the best tools for the job. Having lots of opinions is healthy, and it only really becomes dangerous when we fail to consider other options. Bad options are valuable to us too, because they help us focus on what really *is* important.

Perhaps what's most striking is the fact that our problem solving methods in the software world are sometimes backwards. We have a list of solutions in mind, and we try to see which one fits the problem. From one perspective, this is completely natural. How are we supposed to think of solutions that we don't know of yet? But on the other hand, none of our pre-canned solutions may be a good fit at all. In this case, some research into the problem space may help clear the muddy waters and reveal better alternatives. But how do we know if this is necessary, and we're just not wasting our time? Well, I like to follow the mantra that if it feels like there must be an easier way, then there probably is. In any case, taking a step back and looking around again can be a healthy thing. After all, times change, perhaps faster now than ever before. Yesterday's pitfalls can become today's best practices.

When all you have is a hammer, everything looks like a nail.