Increase Your Depth as a Programmer by Spelunking

Once upon a time I had a sort of game I used to play. It was fostered in part by "downtime" at work, where I had nothing to do immediately, but I couldn't look idle, either. I called it "spelunking." I'd dig into the computer systems that I had access to, trying to find everything on the system that I didn't already know or know about and learn what it was and how to use it.

Unix systems were particularly fun in this regard. I found games I didn't know, and learned how to use utilities that were already on the system that my coworkers were often not even aware were there. I saved my employers a fair amount of money several times by letting them know they already owned the solution to some problem.

Up until the mid 1990s I knew what every program was on several commercial Unix base installations. Then it got beyond me, but I still kept at the game. Now a lot of the game is seeing how many of the old, still useful, tools are still there. The fact that a basic C compiler is typically not part of a normal install of Unix any more bugs me. In my mind it makes as much sense as shipping it without a shell. Nevertheless...

I've also done the same thing with languages. Find some library, some function, some use of a function (or method) that I haven't used before. Then I try to do something useful with it in a program, or apply it to a problem that I've solved in some other way before.

I'll usually start with a specification to find something, but then I'll move to my books. What I often find is that the coverage is awfully homogeneous. I usually find a bit more diversity online in the coverage of any specific item, but often the items covered are fewer than those that appear in books or the original documentation. Sometimes it's clear what sort of problems a feature is meant to solve, other times it's less obvious.

This doesn't usually result in any big revelations or new ways to rework my current project. Occasionally it solves a problem that comes along some time later. More frequently, it gives me a better understanding of the parts of the language I'm already using. I get a better idea of why things are done the way they are, or of ways to divide a coding problem differently to make more effective use of the language.

I'd say spelunking through specifications is second only to reading other people's code as a means of improving my depth in a language. It gets me into things that aren't in my books or that I haven't turned up when looking up something I need to solve a specific problem.