Super-Programming-POWER
Today, I unexpectedly found a very cool parallel between cookbooks, auto-repair manuals, and programming. Who knew that such could exist.
In a cookbook, or as a better illustration a car repair manual, there is a troubleshooting section which serves to link the real world problem, or causes / effects of that problem on the environment to a possible resolution focused on the parts of the automobile. Then each of those sections gives a detailed diagram of this part (usually in exploded format) and it's links to other parts' parts ( sometimes in exploded format ; where all the pieces are disassembled in a 3D view ). Furthermore, it gives a detailed explanation of how to disassemble and reinstall this part to the others. Some steps in this process come along with pictures, which sometimes have arrow pointing out the part described.
Personally, these type of more real-world applications which will affect me directly, ( this is the car I drive to work daily ), and have recipe explanations are very appealing to me. So I found a way to visualize and explain to myself the code I work on which has a rather large number of functions and files that do different tasks, most of which I'm sadly very unfamiliar. So this was my solution:
I pretended that I'm reading this type of manual for the current programming error I'm assigned. I try to visualize the part in question, and create an exploded 3D view of it's parts. Then I try to model it's function based on input and output, in a visual way. The images aren't ever really complete. Actually most times I end up pretending that a class (sorry for the jargon; go look it up :P) is a part of the car, so I really have a picture of some very vague car part in my head. So once I do this, I try to see how this part fits in with the system, which accomplished a more advanced task. But I don't think of the task 1st. I think of the other system in the same way as I did 4 this one, then I imagine, again visually, how they connect ( at the points where they exchange data, or modify data between one another ), and similarly model the logic as buttons, small river pathways, etc. which lead to different possible actions.
In a cookbook, or as a better illustration a car repair manual, there is a troubleshooting section which serves to link the real world problem, or causes / effects of that problem on the environment to a possible resolution focused on the parts of the automobile. Then each of those sections gives a detailed diagram of this part (usually in exploded format) and it's links to other parts' parts ( sometimes in exploded format ; where all the pieces are disassembled in a 3D view ). Furthermore, it gives a detailed explanation of how to disassemble and reinstall this part to the others. Some steps in this process come along with pictures, which sometimes have arrow pointing out the part described.
Personally, these type of more real-world applications which will affect me directly, ( this is the car I drive to work daily ), and have recipe explanations are very appealing to me. So I found a way to visualize and explain to myself the code I work on which has a rather large number of functions and files that do different tasks, most of which I'm sadly very unfamiliar. So this was my solution:
I pretended that I'm reading this type of manual for the current programming error I'm assigned. I try to visualize the part in question, and create an exploded 3D view of it's parts. Then I try to model it's function based on input and output, in a visual way. The images aren't ever really complete. Actually most times I end up pretending that a class (sorry for the jargon; go look it up :P) is a part of the car, so I really have a picture of some very vague car part in my head. So once I do this, I try to see how this part fits in with the system, which accomplished a more advanced task. But I don't think of the task 1st. I think of the other system in the same way as I did 4 this one, then I imagine, again visually, how they connect ( at the points where they exchange data, or modify data between one another ), and similarly model the logic as buttons, small river pathways, etc. which lead to different possible actions.
Labels: method, programming, technique
posted by rivanov at
9:58 PM
2 Comments:
Come to think of it, there are a lot of simularities. They all involve following directions and improvising. I can see how an automobile manual also involved certain objects with well defined properties, methods, and interfaces.
By
Noah Coad, at 9:38 PM
Hello. And Bye.
By
Anonymous, at 10:01 PM
Post a Comment
<< Home