Why write technical blog posts Part 2

Some interesting quotes (with links) from "Apprenticeship Patterns":
 
Section 6: Construct Your Curriculum

" the vast amounts of wisdom captured in the books of experienced practitioners like Jerry Weinberg, Fred Brooks, Steve McConnell, and Kent Beck cannot be replaced, not even with higher-bandwidth information. Even if you’re not a bookworm, a successful apprenticeship needs to include some books as well as time devoted to studying. You’re not in school, though. There is no assigned reading—it’s up to you to find recommendations and construct your own curriculum."

0) Reading List
          "Problem: 
                   The number of books you need to read is increasing faster than you can read them.
        Solution: 
                Maintain a Reading List to track the books you plan to read, and remember the books you’ve read."

1) Study the Classics:

"Joshua Kerievsky once asked Jerry Weinberg how he keeps up with all the books that come out. Jerry said, “Easy—I only read the great ones”
[...]

"Successful apprentices tend to focus on “long-lived books” and use the Web or experimentation to learn how the information has evolved. Dave remembers vividly the experience of reading his first classic in this field, The Psychology of Computer Programming, and marveling at how relevant the book felt, despite the stories of punch cards and room-sized computers. The wisdom captured in such classics is vital information to keep you heading in the right direction on The Long Road."

2) Dig Deeper:

"Problem:

You keep running into difficulty maintaining the code you’ve written because it turns out that the tutorials you followed cut corners and simplified complex issues. You find that your superficial knowledge of a thousand tools means you’re always floundering whenever a subtle bug arises or you have to do something that demands deep knowledge. People often accuse you of having a misleading CV because you don’t distinguish between a couple of weeks of extending an existing web service and a deep knowledge of the issues inherent in maintaining an interoperable and highly scalable enterprise system. What’s even worse is that because your knowledge is so superficial, you’re not even aware of how little you know until something or someone puts you to the test.

Solution:

Learn to dig deep into tools, technologies, and techniques. Acquire the depths of knowledge to the point that you know why things are the way they are. Depth means understanding the forces that led to a design rather than just the details of a design. For instance, it means understanding type theory (or at least the simplification offered by the typing quadrant at http://c2.com/cgi/wiki?TypingQuadrant) rather than simply parroting the things you’ve heard others say"

Why write technical blog posts Part 1

Technical blogs help to:

• Record and speed-up the process of learning a new topic.
• Can be used as learning devices. 
• Provide a useful format for note-taking as you learn new things.
• Sharing and growing knowledge with others.
• Provide invaluable feedback necessary for your own growth.
• Capture the essence of what you learned during research

Technical blogs should evolve from one-liners to concise researched posts.
They should act as brain-dumps of all your research.

Research is a frightfully expensive activity with loads of context building up as you search.
What happens after to all this invaluable context after you spend a week or more researching it?
It evaporates within days of research as you move on to other things.


The beginners mind full of questions is an invaluable resource.
Unfortunately it's impossible to retain as you learn more and more!!


Slowly the questions give way to answers...
Only for more questions to pop-up... with answers following slowly.
The mystery thickens fast as you try to satisfy your quest for understanding.

Researching, reading books, articles, blogs that you browse on the Net, experimenting, theorising, modelling.
All these go into the steaming cauldron of your quest....

Slowly the mists part to slowly yield insights into what makes the thing tick!!


Writing and Revising your blogs is a definite way to nurture and match this process of  growth.
The very process of writing simply and clearly forces you to seek out the core of the concept.
This is THE most valuable gift to the technical blogger - fuelling his own growth while helping others on the path.

Innocence yielding to Experience yielding (very) slowly to Mastery.



Not only does it capture the questions and answers you found.
It can very easily form the basis for helping out someone on the same path.

Why we need Pointers - An Everyday Analogy using Trains/Telephone Number

Everyday Analogy

1) We regularly use pointers in everyday life when we use telephone numbers.
2) Another notable use is in chains and trains (concrete examples of linked lists). A chain is a group of things linked together by malleable joints. These joints are easily changeable when adding/removing new links/compartments to the chain.

Note : 
 a)Telephone no.s give 2-way access whereas a pointer gives only 1-way access.
 b)Usually the no. of links is 1 to 3 in an access path. 

Tom ---> Jerry
Tom ---> 1 ---> Jerry
Tom ---> 1 ---> 2 ---> .... ---> N ---> Jerry

Here Tom calls Jerry by

a)Getting the contact no. directly or indirectly from 'a friend-of-a-friend-of-a-friend'.
b)Dialling the number.

Here the intermediate links of the chain can change the destination similar to an operator diverting your call to the concerned person in an organisation. Say Tom wants some info (from Jerry), but N on the path knows that Mortimer is a better source of info and gives Mortimer's no. instead.

a)Original path:
Tom ---> 1 ---> 2 --->...N --->Jerry

b)Redirection:
Tom ---> 1 ---> 2 --->...N ---> Mortimer

This is similar to shifting tracks for a train, we can easily divert the train to whatever track by using the shunting mechanism.
----
Note:
I'd contributed this article as a section on the wikipedia page for C/C++ pointers, but some time later it disappeared in the rather over zealous editing by the page maintainers who totally mangled it into bits and threw the ashes to the winds. I had to rescue it from the edit history spending a few hours to track down my original post and now it has a permanent home here. I was really gratified to get one comment from one of the reviewers there (talk section). Really made my day that I'd managed to simply convey the heart of pointers to a non-programmer in terms they could easily identify with, understand and even explain to some one else. Why we need pointers at all in the first place.
Good Pointer Fun with Binky Video from Stanford University.