Don’t Be An Expert
Posted by Peter on April 28, 2006
In this post I am going to share a lesson I learned too late with you: never become an expert in anything. Be good at it, but not an expert.
Who is an expert?
Not every programmer is an expert with the tools (environments and languages) they use. For convenience let us call someone an expert when they have mastered a large percentage of the features of the tool they are using, which means not only do they know that these features exist and what they do, but they are familiar with the specific details (for example a Java expert would be familiar with most of the standard libraries, and for the most used parts of the language they would also know possible causes of exceptions and the exact type of exception thrown, as well as the relevant class hierarchy). The expert probably owns books on the subject as well, and has invested money in commercial solutions if they are available (once again, an expert Java programmer has likely bought at least one expensive Java development tool and a whole shelf load of Java books). Personally I don’t think I am an expert in any language, but I am somewhat of an expert with respect to Windows programming. I have invested money in Visual Studio, and am well acquainted with the Win32 API, DirectX, device driver programming, as well as many other diverse topics.
Problems with being an expert
The primary problem with being an expert is that when you have reached this level every task is easiest using the tools you are already an expert with. For example I once dabbled in Perl, but despite Perl’s reputation at being great at dealing with text it took me longer to make a parser for a particular file format in Perl than in C++. This doesn’t mean that Perl is bad, it just means that I am too much of an expert in C++. Once you become an expert it becomes hard to pick up new languages and tools because to pick up these new tools you must work on projects with them. However it is always faster for you to use your old tools, and thus you don’t begin projects using the new tool you were initially interested in, as it always seems more important to get the project done than learn something new; after all you can always learn it later. Thus in the end you remain an expert in what you already know and only expand your horizons when it is literally impossible to accomplish what you want with your preferred tools.
Experts are harmful to the community
As you may know Windows Vista is going to be making a gradual move to a new API. As a Windows “expert” my gut reaction is be opposed to this move. It means I will have to recode my projects, relearn all the intricate details I have picked up, and repurchase new versions of my tools. If Windows was run by the community I am sure that the old API would have been supported forever. Fortunately for progress in Windows it’s not, but there are other languages and tools that are run by such a community. Here I am obviously making an oblique reference to Common Lisp. Common Lisp experts have invested money in the commercial tools, and much like me and Windows they are reluctant to leave that investment behind. Unlike me and Windows however they have a say in what changes are made with respect to Common Lisp, and thus can ensure that the language remains basically static.* Another example of an expert dominated community may be emacs, which hasn’t changed significantly for many years, but since I don’t personally use emacs I can’t say for sure.
How can I stop being an expert?
Good question, and if I knew the answer I would probably be running Linux on my other machine at the moment. I mean I could go and work on my new Lisp implementation under Linux, but that would mean learning how to use gcc, and how to: inline assembly, write naked functions, create dynamically shared code objects, create libraries, manipulate files, do multi-threading, figure out the object file format, invoke the linker within a program, write an installer, and many more tasks that I can already do without too much thinking in Windows. In fact learning how to do these things in Linux would probably take as long as the project itself. I think to myself “maybe I can port it when it is done,” but in reality when it is done I will want to either make improvements or start a new project, not port it to an operating system I rarely use, and thus the cycle reinforces itself. If you have any ideas on how to solve this problem feel free to voice them.
* How do they have such a say if the language has commercial implementations? Couldn’t the company implement new features? The reason the commercial implementations remain basically static is thus: if they wanted to do something radical, like change CLOS, the experts, who are the majority of their customers, would leave for one of the other vendors. Thus the companies are forced to make only little extensions that don’t break the standard.