[[ Sticking with the music theme that seems to keep popping up in my posts. ]]
I’ve recently decided to take up jazz piano again and found a great private lessons teacher in my neighborhood. Frank has been filling in the missing details in my playing. Trying to get me into improvising solos more.
In the quiet moments of practicing, I realize that great improvisers are hodgepodge of licks and ideas they’ve learned from other performers, either live or on recordings. They learn this sweet lick they heard here and that roll trick from over there. What interesting is how their soloing blend these sounds together to create their own voice. They create their own vocabulary.
This idea lends itself to Dave Thomas thoughts on software archeology.
First, when I hear “software archeology” I think of some orphaned software running on a forgotten server somewhere. Some musty dusty software, that some user somewhere still uses, but none of the original developers are around or any of the documentation. Worst yet, it was written with hungarian notation.
But that’s not the case, Dave explains it a way of learning to develop software by learning what developers did before you.
By understanding what the developers were thinking, what influenced them, what techniques they were fond of, and which ones they were unaware of, you will be much better positioned to fully understand the code they produced and take it on as your own.
What really got me is his practice of keeping a “code morgue”. During his archaeology code reading, he’ll put snippets of things he likes and is impressed with and throw it in his morgue. With the code morgue living in a private space, he’s free to periodically review it, experiment with it, and keep the good ideas as reminders. Keeping and maintaing a code morgue is a practice meant to be kept throughout a software developer’s career.
I started this practice without even knowing it. I’ve been using evernote as a personal wiki. I have been placing just pieces code, fragment really, of things that I see while reviewing various open source projects.
One of the first things I put in it was an implementation of static inner class. Conceptually, I understand what it is. If this was a test, I can define it. But what boggles my mind, why would you ever need or want to do this. I could easily find a forum board and ask the question, but it makes a bigger impact on you when you find the answer yourself.
The way I saw it used, was that the static inner class was actually a wrapper class to another class in a third-party jar. From what I can gather, the reason why the developer chose to make it inner and static was because the outer class was the only place that actually used the third-party class. This makes the third-party class abstracted away from the developer’s own code. Outside classes didn’t need to know of its existence. And as long as the method names of the wrapper doesn’t change, swapping out the third-party class for another should not be problem to the application as a whole.
Cool, huh? Now if I can only get my piano soloing to be more like “Dr. John”.