Ravi Mohan's Blog
Monday, August 29, 2005
An Apprenticeship Pattern
Dave Hoover maintains a list of what he calls Apprenticeship Patterns, which are essentially heuristics that help you navigate the transition from being an "apprentice" programmer to a "journeyman" (The terms "apprentice", "journeyman" and "master" come from the terminology of medieval guilds which used these terms to delineate increasing levels of competence at a craft) .
While I am not so sure if the "patterns" format really fits , Dave has a very impressive list of excellent advice . Please go and read them if you haven't (and buy the book when it comes out) .
Recently a friend asked me how to become "as good as you" ( bwaa ha ha haa ) in programming and I drew out a couple of "patterns " from what i told her .
Here is the first
Book Chain
To gain mastery in any given field the best way is often to read and
work through a series of "classic" books in sequence .
Since the books we are speaking about are books about programming there will be plenty of code to write as well.
The problem is that there are often many many books about any
particular subject and it is not easy for an "apprentice" to determine
what to read and in what order . A person who has already walked the
path is often able to guide an "apprentice" in constructing the book
chain .Working through such a reccomended chain of books will save you years of flailing around.
Here are a couple of examples of book chains .
Topic : Compilers
First work through Language Processors in Java (by David Watt ) .
This book gives you a "vertical slice" through constructing an
interpreter for a (fairly limited or "toy" )language .
Then work through Essentials of Programming Languages (Wand and Haynes) .This book gives you deep
insights into how a langauge works "from the inside".
Follow this up with Van Roy and Haridi's "Concepts, Techniques and Models of Computer Programming " which dissects the various programming paradigms and shows how each paradigm is best suited to a particular set of problems
and more importantly what the limitations are . Again Paradigms are best understood by getting an insight into how they work internally rather than as random rules like for example ,"use polymorphism in preference to inheritance" .
Next , read a book (and look at the corresponding source code ) that explains how a production quality compiler/interpreter works .
Three books that fit the bill are Lisp in Small Pieces, A Retargetable C Compiler - Design and Implementation and Compiling with continuations
Now you are all set to look into a real world compiler/interpretr/vm (say the Ruby
Interpreter or the JVM ) .And once you get through that , you are a
"master" (or very close to mastery as makes no difference) .
And now for a slightly less technical example
2. Extreme Programming
First read Kent Becks "Extreme Programming" to get an overall idea .
Then read (and work through ) Test Driven Design by the same author. Learn to use a unit testing farmework like JUnit
Then read and work through Martin Fowler's "Refactoring " and Josh
Kerievsky's "Refactoring to Patterns" ,
and optionally Ron Jeffries's "Adventures in C# " . Learn how to
operate a Continous Integration Framework (like Cruise Control) and how it works,
and then understand how Dependency Inversion works and learn to use a Mock Objects framework like JMock.
.
Follow this up be learning how to break up required functionality into
stories . To learn more about
the XP process read Jim Highsmiths book on Agile Project management , and optionally the Scrum book .
And there you are .If you have learned (and more importantly applied ) all these concepts , you are an XP "master" .
The best way to get a "book chain" for a topic you intend to specialize in is to ask someone who is already expert in the field to give you a sequence of books to study.
A poor second option is to find the "best book to begin with " (for Artificial Intelligence , this is Norvig and Russell's "Artificial Intelligence, a Modern Approach", for example ) and pick and choose from the bibliography.
Subscribe to:
Post Comments (Atom)
4 comments:
Thought provoking ideas. Dave Hoover's work seems to be very interesting. Learning is always a continuous process.
I liked what you have to say about building book chain. My take on the process books is that it is not just enough to read books, what matters most is whether you are able to appreicate the underlying value/principle. I have seen so many, who claim to have read books, but miss the whole point.
Baps, You are right of course. You may have noticed that through out the post i say "work through" the books. In the case of programming books, this would involve writing code. For process books this would involve actually putting into practice the various steps of the process .Like in any other craft, book learning has to be supplemented with experential learning .I agree completely
How long do you think it would take to attain a " very " good command of Java?
Iam moving to Java from MS technologies. Can you please suggest me a book chain?
hmm. When anyone asks me how long it takes to be *very good* at any language , I point them at Dr Norvig's advice .
However , if as you are very good at C# or VC++ (VB is not a "technology", imho) and are already familiar with the "classics" of your domain (for eg: In Enterprise sw, Martin Fowlers "Patterns of Enterprise Application Architecture ", then , getting the hang of the Java *language* won't take too long.
The only reasonably "tough" part of java is its concurrency library.If you are doing Enteprise software you won't need this .
If you have to master this, it should take you about 4 -6 months of very hard work (Use Doug Lea's "Concurrent Programming in Java") .
Now if you are just starting out with OO (ie no C# or c++ experience) then you have a very long way to go . Start with Bruce Eckel's "Thinking in Java" .Read some of the books my friend Yogi suggests .
Post a Comment