A couple of weeks ago, I was called to solve a problem on a project. I had no particular expertise in the task at hand: XPath. We had to write an XPath expression to find a piece of data inside an xml document.

Both the XPath processor and the xml document generator (it was being generated automatically) were black boxes. That means we couldn’t change the xml file nor the XPath processor. The problem was a simple one: The XML document was generated with a default namespace, and we didn’t knew how to process it. I wrote a (simple) XPath processor to test the behavior of the expressions we were using and, after an hour or two, we discovered the problem and the solution (For the curious: we were using //<tagname> and had to use //*[name()='<tagname>’]. To check the difference, RTFM).

Then I asked myself: Why were I trying to get a solution to the problem before getting a deeper understading of the underlying technology? Then I realized that this behavior divides programmers in two groups: Scholar programmers X Practical programmers.

The Scholar programmer is the one that, reagardless the time/cost constraints, is only worried in learning. He manages to get some things done once in a while, but it is not that common. He is mostly worried in learning, and is closely related to Resume Driven Development. This guy can be useful to your team, if you can make him work based on deadlines.

The Practical programmer is the entire opposite. For him, the important stuff is to get things done right away. He is obsessed with solving the next big problem. Do not be fooled: This guy can ruin your team. He will get things done and all… But he will not learn new stuff. He insists that you should keep using your old solutions, instead of trying new stuff. In the end, his short term decisions will make everyone’s life harder.

Obviously, no one can be 100% on one side nor on the other. “Virtue is in the middle” applies really well to this situation.

So, where do you fit better?