Apprenticeship Patterns: Patterns and Anti-Patterns of Problem-Solving

The Intellectual Side of Problem-Solving:

(Borrowing heavily from AI terminology)
Imagine a 3D Cube containing the start-state, the goal-state, the problem-space and the solution-paths.
You're essentially scanning a problem space for a solution i.e. a combination of sub-steps which finally lead to goal.
1) Explore the problem space first i.e. try out things
2) Identify what worked or is promising and extend the branches into the sub-problem spaces
3) Recurse over the sub-branches until you've covered enough of the problem-space.
4) If the volume of the problem-space is vast it may help to BackTrack from Goal towards the problem state.

This reduces the volume of problem-space to be probed for possible solution-paths. This is known an "Alph-Beta" Pruning of the (Decision??) Tree.
//TODO: Add Diagram of 3D Problem Space and Decision(??) Tree.


In Nature, Lightning follows a very similar method of Back-Tracking.
It seeks out the easiest path between cloud and ground through an insulating volume of air.
Actually there is an initial weak backtracking path from ground to cloud, followed later by a strong return path.
//TODO: Add picture of Lightning fingers

The Emotional Side of Problem-Solving:

Basicially we must first ask "Why" is problem-solving so important?
Not all problems we face are life-threatening to require immediate attention.
So then what is it that makes solving them so important in the first place.

Refer:
1) Psychology of Computer Programming by Gerald Weinberg
2) Emotional Intelligence

Experience - coming to terms with "immediate failures" vs. "future pay-offs"

1) Try out many things to get a better solution or a solution which appeals to your way of doing things.
2) All the things you try won't/can't succeed at least immediately.
   Mostly many of these "dead-end branches" are just waiting for the right time to flower. You're actually building up a fund of ideas and efforts which will help you overcome some other obstacle.
   Example:
   Unix was a result of dissatisfaction with implementing Multics which itself was a replacement for some other O.S.
   Ken Thompson went on to implement ideas for distributed O.S in CODA, Plan9 etc. 30-40 years later these lessons learned and 'the-roads-tried-but-not-taken' have resulted in writing a 'go' language.
   It's used in Google which puts those same ideas refined over time into concrete working programs.

3) Watching my son getting frustrated when his cycle got stuck in a corner.
   He'd start screaming and banging the cycle into the wall.
   Beating it with red-face and small fists.
   The tears of frustration and incomprehension as to why the universe conspired against his cycling.

4) This felt so much like my own frustration with my own efforts.
   The perceived low return-on-investment of the "meagre" results.
   So many ideas half-implemented, unimplemented and ALL the wonderful things not even attempted i.e. 'the-road-not-taken'.
   The universe almost conspiring to thwart each hope and attempt at magically succeeding at all things.

5) Frustrations comes from other people's expectations.
   And more so our own awareness of not "measuring-up" to their and our own expectations.
   Perfectionism adds heavily to an already sticky situation.
   A feeling that time is running out.
   The impending joining of ranks with washed-out oldies.
   A feeling of helplessness and hopelessness that things can't/won't change no matter what.  
   Unable to leave coding and unwilling to change to management (manipulating people not machines).
   Fear of becoming obsolete, of not living up-to the dreams, hopes and self-expectation built up over the years.

----

Patterns: The Middle Path between the Emotional and Intellectual Sides of Problem-Solving

"Why patterns work?!!" AKA "All I needed to know about Patterns I learned in Kindergarten"

Patterns force you to Think and NOT concentrate so much on the Feeling part (which is the cause of frustration)
a) Read, understand, see how the Pattern fits the Problem.
b) Re-evaluate the problem itself.
c) Try carrying out/coding the Pattern.
d) Customizing the Pattern to the situation.
e) Utilize your Feeling side by reflecting on aesthetics as pattern application is a very qualitative activity.

Patterns are primarily a set of ready-made formulas (cookbook-style) for successful problem-solving.

Raise Flagging Hopes:

These are also sufficiently magic-endowed by hearing good things from others etc. This helps you get over the inertia of hopelessness or feeling stuck at a problem. "Who knows this just might work - I've nothing to lose."

Abstract the problem solving process.

De-personalise the problem takes the bite out of it.
If the trial fails it's just the Pattern failing NOT you.
You're fore-warned to try out different patterns for different circumstances.
So you just try some other Pattern or just do something else.
Since the Pattern comes from outside, you give yourself time to understand it.
This is the crucial part where you become accepting of time and effort to customize the Pattern to your particular situation.

Conclusion:
Patterns are very effective Devices for Distraction from Result and Focus onto Process instead.

1. Failure Modes of Hacker Schoolers : https://www.hackerschool.com/blog/66-four-failure-modes-of-hacker-schoolers

Steps towards Technical Mastery

How do you know if you've become a Master in your field?

Is there any method to learn things quickly in any field?
How do you avoid stagnation and mediocrity after becoming competent in your field?
How do you become a Master?

Take software for example: How do you become a Master in it?

These are exactly the questions which have been pushing me to seek answers.
Well now that I've got some kind of grip on this quest I'm able to give some of the answers.
Or at the very least point the way.

Short Answer: You'll know it when you get there!!
Long Answer: You'll see the Sign-Posts as you move towards achieving Mastery. Read on for the gory details.

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.

Mindmap of my observations/experiences in "Apprenticeship Patterns Applied"