If you write code for a living, no matter what language, flavor, or IDE, sooner or later you begin to develop/write code to a set of unwritten rules that experience has taught you. Sometimes these rules are based on great, hard won lessons, wrested from spectacular failure or success. (Both failure, and success are great learning opportunities.)
Other times they are holdovers from some other project or something you learned from someone else. Or even something you just do but can't explain. My favorite story about the genesis of those kind of rules is as follows.
Child watches Parent making a meatloaf, after the meatloaf is made, Parent takes it out of the pan and cuts about 2 inches off one end and then puts it in the oven. Child ask's Parent why they always cuts 2 inches off the meatloaf? Parent pauses for a moment and says they are not sure why, but their Parent always did that. They decide to call Grand Parent and ask them, Grand Parent thinks for a minute and says it's because their Parent also did the same thing. A quick IM to Great Grand Parent asking why this was done results in the response: "Cause my oven was small and a full size meatloaf would not fit!"
Sometimes, we continue a practice out of habit, not because the need is still there. Most of the time this is fine, but sometimes we unconsciously propagate a behavior or methodology that has lost it's meaning or usefulness over time. Sometimes even to our detriment. It is useful therefor to question why we do things the way we do every now and again. A few moments of introspection can lead to an "Ohhhhh" moment.
I recently experienced such a moment when I was explaining some code I had written to another developer. Once I had finished my explanation they asked me a series of questions about why I did it this particular way as opposed to another. My knee jerk response was "because it's the best way" followed by an unspoken "that I am aware of".
The discussion continued and I soon learned that the method I was using was not only obsolete but was potentially dangerous because of changes in the underlying structure of the language I was using. Changes I was not only ignorant of, but which made a much more robust solution possible.
The method, involving collection classes, that I was using was one I had been using in one form or another for years. I was so comfortable with it, that I had ceased to question it, or look for alternatives. I had developed a blind spot when it came to that particular topic because I was so deep in my personal comfort zone that I subconsciously did not want to move away from it.
This is also an example of the benefit of pair programming, TDD and agile methodologies. To a lessor extent the same results can occur in any team environment. Looked at another way it is an example of why solo developers sometimes do not fare as well. Not having a team to bounce ideas off, or to have question and challenge you on assumptions and approaches can often lead to practices that become bad habits.
That is not to say that all solo developers progress less slowly or that all teams progress better. There are plenty of examples out there of "Toxic Teams" and solo Super Hero coders. But it is nice to be exposed on a daily basis to others points of view, experience and skills. You can derive a lot of the same level of benefit, albeit less interactively, by reading blogs, and participating in development forums all over the net.
But every now and then, solo or team member, you should stop, reflect, and refactor your own thinking process and assumptions. Weed out the things that no longer work for you, and try and replace them with things that do. Learn something new, test it against your own experience, if it seems to fit consider making a new habit to replace an older one!
Cheers,
Robert Porter