Understanding the Possibilities
I maintain that there are several different levels of “knowledge” when it comes to being a developer and working with technology. Consider.
Knowing that something can be done, and knowing exactly how to do it: If only we could always be this way. I discussed this in the past in a post about memorization, and it’s self-evident that this is the best kind of knowledge to have.
Knowing that something can be done, because of some past experience: This is the majority of my knowledge. Give me some development scenario, and I’ll often remember something I read somewhere, or saw in action, or did myself. I know it can be done, somehow, but I need a refresher on the specifics.
Having confidence that something can be done, but not knowing for sure: This usually comes from experience with a platform. Certain platforms inspire more confidence than others, and you get in a “vibe” with the developers you never met. A situation will come up, and you’ll just know it has a resolution. Usually, you’re right.
The fact is, there’s no way for any of us to memorize everything we need to do with Platform X without years and years of experience. So, we often take the next best option: just being cognizant of what’s possible, with the knowledge that you can find out the specifics when you need to.
Just this morning I was cruising through Google Reader and found a post about launching asynchronous tasks in ASP.Net. That could come in handy, I thought. I clicked through, read the article, and developed some understanding and framework of what they were trying to do.
Could I actually do it now? No, but I know it’s possible, and my frame of reference for the platform has expanded. If a situation were to come up where an async task would be the solution, it’s hoped that I would remember that snippet of knowledge.
This month, I’ve been involved in a fairly monstrous eZ publish/Salesforce integration project. To this end, I went and got a couple books on Salesforce, just so I could understand the platform from a user’s standard and know what all the moving pieces are.
I’ve been blowing through these books concurrently – I read a couple chapters in one, then switch to the other, etc. Turns out that Salesforce is a massive platform with a crazy amount of stuff to learn. Am I remembering exactly how to do everything I’m reading about? How to merge contact records, convert leads, customize the interface, etc.? No. But I’m learning what’s possible, and when a situation comes up, I have a good chance of remembering something I read that would work, even if I have to Google something or grab a book and ruffle the pages.
There’s value in skimming. Buy a technical book, and just read it at a high level. In a larger sense, cast a wide net – read a lot, even if you don’t diligently study one particular aspect of anything. Even if you don’t actually implement any of the code or do any of the exercises, you gain an understanding of your options, and this comes in handy a dozen times every day in the life of an average developer.
(Looking back over this, I’m struck by how completely contradictory this post is compared to these other two:
This fact depresses me a little.)