Stop the world, I want to write it all down!
-attributed to Donald Knuth
Permanent Students
In my opinion, a programmer can do his job in the most productive way by believing that he is always a student. There are always multiple paths by which to solve a problem with code, and it takes experience to learn which is the best. We must constantly be learning, for the technology and methods improve so rapidly that without learning, we quickly fall behind our peers. I've been lucky in that most of the developers I've worked with so far have taken this "permanent student" philosophy to heart.
Due to this mindset, a lot of programmers and developers that I meet have a deep-seated need to understand all possible solutions to their problem. They must be able to take each one apart and put it back together blindfolded before they can feel comfortable that they comprehend what the solution is supposed to do. For the most part, this is a good thing. It enables us to learn, to gather more information, and use that data to create new and better applications.
As a programmer living in the age of technology, I cannot imagine how (or even if) programmers held this mindset before we had the Internet. It has put the sum of human knowledge at our fingertips; any problem we have is only a quick search away. Hard copy books, the learning paths our coding forefathers used, are quickly becoming irrelevent, and the Internet is opening doors faster than we can look into the rooms. We, the permanent students, have the ability to study anything we wish. And because we are smart enough to recognize that we are almost always not the first person to have a particular problem, it's really easy to assume that the Internet must be able to provide an answer.
Analysis Paralysis
But the sum of human knowledge is effectively limitless. We programmers crave knowledge; it is embedded within us, the foundation for our skills and experience. So what happens when people who have such a basic need to understand everything meet a limitless amount of information? In my experience, many programmers will enter a state known as analysis paralysis, an inability to make a decision because it is not obvious which solution is better.
If you've ever had two equally-good solutions to a task, and just couldn't decide between them, you've been in this state. I've lost hours, even days, crawling down rabbit hole after rabbit hole in search of the obvious piece that I must be missing so I can just prove one of these solutions correct and move on. I've thought, on multiple occasions, that I must understand each of these solutions fully before I can use any of them. The answer is here, somewhere on the internet, I just need to find it. And so I trudge along, wearily searching for but never locating that elusive Rosetta Stone which will distinguish the potential solutions from one another. Eventually I just give up the search and mentally flip a coin to decide which path is the better choice.
Almost always, I should have flipped that coin much sooner than I did.
Sometimes our underlying need to understand hampers our ability to just make a decision. Programmers are analytical people by nature, and analytical people can have difficulty seeing the forest for the trees, seeing the overall machine without looking at the components. We must break the puzzle into pieces and study them in the hopes that we can put it back together in a more "correct" way. And since we can learn about each of the pieces, why shouldn't we? Shouldn't we try to make the most informed decision possible, since that's probably going to lead us to the best solution?
Just Pick One
Yes, of course, to a point. However, we should remember that focusing on the pieces can make us lose sight of the puzzle. We must keep eyes on the problem we are actually trying to solve, not just the individual parts we are trying to fit together. If we have multiple ways to solve the puzzle and can't prove which is better, we need to be prepared to simply make a decision and go with it until and unless it is proven inadequate.
Sometimes there is not a perfectly correct way, there is only your way. The trick is to notice when analysis paralysis is happening, before you've spent days trying to sort out which solution to use. If this happens, and you and your team can't come to a consensus, just pick one. At the very least, you won't have wasted time searching for the perfect answer. You may even find that your first choice, your gut instinct, was the right one.
The peril of infinite knowledge is that it conditions us programmers to think that, because we are probably not the first person to encounter a particular problem, there must be a single, correct, final answer for said problem. Most of the time this is simply not the case. Sometimes we have to go with our gut, or maybe even flip a coin, and hope for the best. Don't be afraid to flip that coin!