I read a post somewhere (unfortunately, I can’t find the link) to the effect that “a good programmer should learn as little as possible while coding.” At the time, I simply scoffed and moved on to the next posting (as evidenced by the fact that I didn’t save the link). However, it stuck in the back of my mind and continued to nag at me. On reflection, I’ve decided that there is a deeper point there.
To get at the deeper point, it’s probably best to think of a different frame of reference. Think of a craftsman; a musician, or a master potter. The craftsman spends years learning his craft, from the very basics to the finest subtleties. The best craftsmen continue to learn new tricks and techniques throughout their careers. But in general, when the craftsman sits down to do a piece of work, he already knows all the techniques that will be necessary to do the work. That is, he knows what he’s doing.
There are times when you purposely take on a “research and development” project, where learning new things is an explicit part of the plan. But for the most part, you should have a pretty solid handle on the things you need to know before the project starts rolling. If you have to do a lot of on-the-job learning in the midst of a project, there are a number of bad outcomes that can happen:
1) Documentation for some products can be pretty awful, and may be non-existent. If you have little or no documentation for an API, you’re basically forced to guess and reverse-engineer a solution based on whatever fragmentary information you can summon up in your search engine.
2) You’re much more vulnerable to making errors if you’re using a new API.
3) Learning takes time. If you have to stop and search for info frequently, you’re slowed down substantially.
So, given that:
A) You need to continuously learn new things in order to stay current in your field.
B) You don’t have a lot of spare time to learn while in the middle of a project.
What do you do?
A few ideas:
1) Prototype early. As soon as a project gets underway, prototyping should begin. When prototyping, the focus should be on integrating the technologies to be used, so that by the time development begins in earnest, you’ve shown that the technologies will work together, learned how to use them.
2) If you’re working with new tools, expect to encounter some issues, and plan for it.
3) If you’re working with truly experimental technology, have a “Plan B” in case the technology proves to be insufficient for production use.
4) Use a “facade” pattern to insulate your code from the specifics of the API. This gives you a great deal of flexibility later in the project’s life, if you have to replace one vendor’s API with another. Beyond that, it allows you to abstract away the details of the API; you simply build an interface that provides the functionality you need, and hide the details of the implementation within the facade wrapper class.