Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re: Swallowing an elephant in 10 easy steps

by biohisham (Priest)
on Aug 14, 2009 at 21:06 UTC ( [id://788749]=note: print w/replies, xml ) Need Help??


in reply to Swallowing an elephant in 10 easy steps

Over the past few hours, I have been trying to identify with these 10 steps. The suggestions and ideas you graciously shared are reflection-inducing. Starting off, these ten steps are like beads to a string, I had the notion that this is so much of a teaching-material quality, because you have addressed two interleaving concepts, the Database issue and the Programming one. So seriously consider having this published and displayed on a wider scale to those whose interests fall inside these concerns. I mean after having duly taken into accounts the many suggestions and inspirations that would pour.

within the points 3-6, the area where scanning, categorizing and tracing is more crucial, Exploring the type system can by far be one of the toughest takes especially while exploring the code structure and the classes relationship on one hand and on the other if a database is involved, the records types. The flow between classes and the events that trigger these classes, the associated variables and scopes are all places where an attention has to be sharp, refined, present, so without a clear understanding of the data streams and the way things go, and how these data travel through classes and code back and forth with the combined ability to visualize them in that act, a correlation between these two steps can be illusive.

As I said I have been trying to identify with these gems, It appears to me that you have a programming style that is -if I may say- based on characterization, for something to be cognizable enough it has to have this character to it serving as a dimension with every involved character behavior pretty much as in a story, interleaving, associating, working together... but I am failing to reach to figure how I can read the plot from the code and where the main knot of it is.

With regard to the time constraints, you have dealt with fairness at addressing the time requirements and the spaces while bearing in mind the iterative nature of the process. That is an admiration of skills I have for you, I look up to this level of stability. :).. Thanks for sharing this with us...


Excellence is an Endeavor of Persistence. Chance Favors a Prepared Mind.

Replies are listed 'Best First'.
Re^2: Swallowing an elephant in 10 easy steps
by ELISHEVA (Prior) on Aug 15, 2009 at 21:12 UTC
    but I am failing to reach to figure how I can read the plot from the code and where the main knot of it is.

    The metaphor of story may not work for everyone. If I were to deconstruct the concept of story, I would point to two key features of well-written stories:

    • Every detail of the story has a place. There is nothing superfluous. Everything plays a role in developing either the plot or the characters or the fundamental message (a.k.a. theme) of the story.
    • It is possible to step back from the story and construct a narrative to explain the role of each detail in the story.

    A good choice of categories for database tables lets us assign a role to each table. Once we have a set of roles we can try to construct a narrative to explain how each of those roles works together to create a whole system. The question is: have we created a well-written story?

    In particular, our narrative needs to explain how the categories we've chosen give the front end the data it needs. We also need to explain what functionality could explain the data that has no obvious connection to the front end and how it may related to the goals of the end-user view of the system. Maybe it helps performance? Supports development? Represents related, but unused features? Solves an architectural problem related to system design? Sometimes it is obvious what kind of functionality this extra information might support. If it isn't, we can put them aside for a bit and hope that maybe their purpose will be clearer when we see whether or not the code uses these tables, and if so how.

    However, if we find more than a few things we can't categorize or our categories don't seem to fit together, then we also need to take a hard look at the way we are categorizing.

    According to psychologists who specialize in memory and cognition, experts and non-experts differ significantly in the way they use categories to organize information:

    • experts organize information using more categories than non-experts
    • these categories tend to reflect deeper principles rather than superficial features.
    • these categories are cross referenced to each other in ways that make it very fast for experts to retrieve information and apply it to new problems in their area of expertise.

    For example, a novice might try to group database tables based on structural features like primary key or the presence of blob fields. However, she is likely to find it very difficult to use these categories construct a narrative explaining what she saw on the front end because the categories are too superficial. Since she can't compose a narrative, she has to rethink her categories. If she is lucky, trying to construct the narrative to explain how the data supports the front end might hint at another more meaningful way of categorizing tables. If not, a smart novice will find someone with more experience and ask them how they might organize the tables. Sometimes we do need to learn by watching the example of others. If there are no handy experts, she might try one of the approaches here or here to get her creative juices going.

    The goal of the emphasis on story is to help one question one's categories until they are deep enough to be useful. The iteration and interleaving of code and data and focus on flow are also meant to help enrich the connections between categories and make it easier to retrieve information when you need it. A nice summary of the role schemas (categorization systems/stories) play in expert knowledge can be found here.

    Here also some links to research on expert knowledge for software programming and development. I found a few interesting observations here and there about the role of data and code but none of these seemed to say much about learning systems whole.

    • Expert Programming Knowledge: a Schema-Based Approach - dense review of research literature, 2007. One conclusion was that research results may depend on what language the programmer was used to programming in. COBOL programmers apparently found it easier to understand data relationships than Fortran programmers.
    • Roles of Variables in Teaching suggests that experts cluster a lot of tacit knowledge around the various roles variables play in programs. Teaching that explicitly may help students learn to build better programs.
    • Applying Cognitive Load Theory to Computer Science Education has a few speculative comments towards the end about the role schemas might play in reducing cognitive load. Apparently there isn't a lot of research on how schemas can reduce information overload in programming.

    Best, beth

    Update:in process, to be added: links to articles on expert schema research specifically in the field of computer programming added.

    Update: revised research links to describe information in each article relevant to understanding systems and data/code relationships.

    Update: added links to monkish brainstorming of what to do when you are really stuck trying to understand something.

    Update: clarified the deconstruction of "story".

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://788749]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (6)
As of 2024-04-18 06:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found