From: Ruben Beltran del Rio Date: Sat, 17 Dec 2022 22:13:35 +0000 (+0100) Subject: blog-sync-up-1671315215521 X-Git-Url: https://git.r.bdr.sh/rbdr/blog.unlimited.pizza/commitdiff_plain/9f0616ad933386785bdd16b0069f2f1c6ef44648?hp=914f0294ef384074d8656701dad64aa4ac5d8212 blog-sync-up-1671315215521 --- diff --git a/archive/1671315215263/metadata.json b/archive/1671315215263/metadata.json new file mode 100644 index 0000000..6d86ee5 --- /dev/null +++ b/archive/1671315215263/metadata.json @@ -0,0 +1,4 @@ +{ + "id": "1671315215263", + "createdOn": 1671315215263 +} \ No newline at end of file diff --git a/archive/1671315215263/reading-hermeneutics-and-the-block-model.gmi b/archive/1671315215263/reading-hermeneutics-and-the-block-model.gmi new file mode 100644 index 0000000..fd9c48d --- /dev/null +++ b/archive/1671315215263/reading-hermeneutics-and-the-block-model.gmi @@ -0,0 +1,71 @@ +# Free Voluntary Reading, Hermeneutics and the Block Model: Acquiring Expertise in Problem-Solving with Code + +Software Engineers never stop learning, no matter the skill level: You need to adapt to evolving circumstances, learn new tools, and face new challenges. + +More experienced engineers tend to have an easier time learning new tools and solving new problems, so what's the difference between them and someone just getting started? + +## Novices Solve, Experts Analyze. + +A 1979 study by Jill H. Larkin and Frederick Reif analyzed differences between novices and experts solving physics problems: The former would translate the problem to math first, while experts started by building a "low-detail" model to understand which principles applied. [1] + +By checking that this low-detail construction fit a model without intractable issues, they had a good idea of what equations and principles they would need to apply before creating a mathematical model. On the other hand, novices took longer to discover this as the right concepts only became apparent while trying to solve the equations. + +This same type of behavior is evident in Software Engineering, where upfront analysis, requirements gathering, and decisions on the right tools result in better outcomes: "Measure Twice, Cut Once" [2] + +An upfront analysis is valuable but not easy to do in practice, even if you know the principles behind it: Just reading a book on software architecture won't give you the insight to know where it's best applied. + +## Knowing the right tools is not enough: Organizing Knowledge is Key. + +To properly analyze a problem, having a toolbox of principles is not enough: It's necessary to have a coherent organization of these concepts that lets you evaluate at the general level and then iterate to the specifics. + +Are there tools we can use to build this organization of knowledge and acquire a better approach to problem-solving? Here I explore three tools I believe can work together to help in this effort: Free voluntary reading, the block model, and the hermeneutic cycle. + +## Free Voluntary Reading is Beneficial for Language Acquisition. + +Dr. Stephen Krashen is a linguist that has done extensive research in the field of language acquisition and the role comprehensive input plays in our ability to speak. + +One of the most effective methods for acquiring language is practicing free voluntary reading, which produces better results than direct instruction. Not only that, but reading is also a solid indicator of good writing. [3] and similarly, a working group has found that program comprehension is critical for writing good programs [4], and they propose a model to teach this. + +## The block model is a Great Way to Divide Program Comprehension. + +In 2008, Carsten Schulte (who later formed part of the above working group) proposed a model to teach program comprehension by looking at a program through 2 axes [5]: + +1. Four levels of "granularity": Atoms, Blocks, Relations, and the Macro-structure of the program. +2. Three dimensions of meaning: Text surface (Connotation or "what does it say"), Program execution (Operation or "What happens"), and Function (Denotation or "why") + +The combination of these two axes provides different types of analysis that might be required to understand the text, from atoms at the text surface level to the macro-structure at the functional level. + +This type of analysis can be complex even for experienced engineers, as it requires moving between structure and function. This transition between the parts and the whole has a lot of similarities to the practice of Hermeneutics, where we can find a helpful method for text interpretation. + +## Hermeneutics ties the whole to the parts, and then back again. + +Hermeneutics is a theory and methodology for interpreting texts, that considers how our experience influences our understanding. + +We can see the analysis a cycle: +1. When we consider the whole of a text, our pre-existing assumptions and knowledge give us a better contextualization of what the parts are +2. When we consider the parts, we gain a better understanding of how they come together to form a whole +3. Repeating steps 1 and 2, we gain a more refined understanding. + +This process of understanding is not fixed and will vary over time: our needs change, we have a different mix of skills in the team, we need the program to operate at a different scale, we have to adapt to advances in the environment, etc. Revisiting programs is a frequent occurrence in every software engineering team. + +## Combine all three and learn to write better code by reading. + +With these three tools in mind, a team can improve their understanding of programs and problem-solving skills through reading. + +Run this session on your own or, even better, with a group of your peers: + +1. Pick a piece of code: it can be written by the team, an open-source project of interest, or some of the dependencies in use. +2. Use the block model to pick an area of focus. +3. Read the code and take notes. +4. Use the hermeneutic cycle to shift from one dimension to another and note how your understanding changes. What assumptions changed? What new insights did you get? + +The more you do this, the more your comprehension will improve, and the better you'll be able to organize and apply problem-solving concepts. + +### References + +[1] Larkin, J.H., & Reif, F. (1979). Understanding and Teaching Problem‐Solving in Physics. +[2] McConnell, S. (2014). Code Complete (2nd ed.). Microsoft Press. +[3] Krashen, S. D. (2004). The power of reading: Insights from the research, 2nd edition (2nd ed.). Libraries Unlimited. +[4] Izu, C., Schulte, C., Aggarwal, A., Cutts, Q.I., Duran, R., Gutica, M., Heinemann, B., Kraemer, E.T., Lonati, V., Mirolo, C., & Weeda, R. (2019). Fostering Program Comprehension in Novice Programmers - Learning Activities and Learning Trajectories. Proceedings of the Working Group Reports on Innovation and Technology in Computer Science Education. +[5] Schulte, C. (2008). Block Model: an educational model of program comprehension as a tool for a scholarly approach to teaching. International Computing Education Research Workshop. +[6] Wikipedia contributors. (2022, September 28). Hermeneutics. Wikipedia, The Free Encyclopedia. https://en.wikipedia.org/w/index.php?title=Hermeneutics&oldid=1112903434 diff --git a/posts/0/metadata.json b/posts/0/metadata.json index 4135728..6d86ee5 100644 --- a/posts/0/metadata.json +++ b/posts/0/metadata.json @@ -1,4 +1,4 @@ { - "id": "1671026528081", - "createdOn": 1671026528081 + "id": "1671315215263", + "createdOn": 1671315215263 } \ No newline at end of file diff --git a/posts/0/reading-hermeneutics-and-the-block-model.gmi b/posts/0/reading-hermeneutics-and-the-block-model.gmi new file mode 100644 index 0000000..fd9c48d --- /dev/null +++ b/posts/0/reading-hermeneutics-and-the-block-model.gmi @@ -0,0 +1,71 @@ +# Free Voluntary Reading, Hermeneutics and the Block Model: Acquiring Expertise in Problem-Solving with Code + +Software Engineers never stop learning, no matter the skill level: You need to adapt to evolving circumstances, learn new tools, and face new challenges. + +More experienced engineers tend to have an easier time learning new tools and solving new problems, so what's the difference between them and someone just getting started? + +## Novices Solve, Experts Analyze. + +A 1979 study by Jill H. Larkin and Frederick Reif analyzed differences between novices and experts solving physics problems: The former would translate the problem to math first, while experts started by building a "low-detail" model to understand which principles applied. [1] + +By checking that this low-detail construction fit a model without intractable issues, they had a good idea of what equations and principles they would need to apply before creating a mathematical model. On the other hand, novices took longer to discover this as the right concepts only became apparent while trying to solve the equations. + +This same type of behavior is evident in Software Engineering, where upfront analysis, requirements gathering, and decisions on the right tools result in better outcomes: "Measure Twice, Cut Once" [2] + +An upfront analysis is valuable but not easy to do in practice, even if you know the principles behind it: Just reading a book on software architecture won't give you the insight to know where it's best applied. + +## Knowing the right tools is not enough: Organizing Knowledge is Key. + +To properly analyze a problem, having a toolbox of principles is not enough: It's necessary to have a coherent organization of these concepts that lets you evaluate at the general level and then iterate to the specifics. + +Are there tools we can use to build this organization of knowledge and acquire a better approach to problem-solving? Here I explore three tools I believe can work together to help in this effort: Free voluntary reading, the block model, and the hermeneutic cycle. + +## Free Voluntary Reading is Beneficial for Language Acquisition. + +Dr. Stephen Krashen is a linguist that has done extensive research in the field of language acquisition and the role comprehensive input plays in our ability to speak. + +One of the most effective methods for acquiring language is practicing free voluntary reading, which produces better results than direct instruction. Not only that, but reading is also a solid indicator of good writing. [3] and similarly, a working group has found that program comprehension is critical for writing good programs [4], and they propose a model to teach this. + +## The block model is a Great Way to Divide Program Comprehension. + +In 2008, Carsten Schulte (who later formed part of the above working group) proposed a model to teach program comprehension by looking at a program through 2 axes [5]: + +1. Four levels of "granularity": Atoms, Blocks, Relations, and the Macro-structure of the program. +2. Three dimensions of meaning: Text surface (Connotation or "what does it say"), Program execution (Operation or "What happens"), and Function (Denotation or "why") + +The combination of these two axes provides different types of analysis that might be required to understand the text, from atoms at the text surface level to the macro-structure at the functional level. + +This type of analysis can be complex even for experienced engineers, as it requires moving between structure and function. This transition between the parts and the whole has a lot of similarities to the practice of Hermeneutics, where we can find a helpful method for text interpretation. + +## Hermeneutics ties the whole to the parts, and then back again. + +Hermeneutics is a theory and methodology for interpreting texts, that considers how our experience influences our understanding. + +We can see the analysis a cycle: +1. When we consider the whole of a text, our pre-existing assumptions and knowledge give us a better contextualization of what the parts are +2. When we consider the parts, we gain a better understanding of how they come together to form a whole +3. Repeating steps 1 and 2, we gain a more refined understanding. + +This process of understanding is not fixed and will vary over time: our needs change, we have a different mix of skills in the team, we need the program to operate at a different scale, we have to adapt to advances in the environment, etc. Revisiting programs is a frequent occurrence in every software engineering team. + +## Combine all three and learn to write better code by reading. + +With these three tools in mind, a team can improve their understanding of programs and problem-solving skills through reading. + +Run this session on your own or, even better, with a group of your peers: + +1. Pick a piece of code: it can be written by the team, an open-source project of interest, or some of the dependencies in use. +2. Use the block model to pick an area of focus. +3. Read the code and take notes. +4. Use the hermeneutic cycle to shift from one dimension to another and note how your understanding changes. What assumptions changed? What new insights did you get? + +The more you do this, the more your comprehension will improve, and the better you'll be able to organize and apply problem-solving concepts. + +### References + +[1] Larkin, J.H., & Reif, F. (1979). Understanding and Teaching Problem‐Solving in Physics. +[2] McConnell, S. (2014). Code Complete (2nd ed.). Microsoft Press. +[3] Krashen, S. D. (2004). The power of reading: Insights from the research, 2nd edition (2nd ed.). Libraries Unlimited. +[4] Izu, C., Schulte, C., Aggarwal, A., Cutts, Q.I., Duran, R., Gutica, M., Heinemann, B., Kraemer, E.T., Lonati, V., Mirolo, C., & Weeda, R. (2019). Fostering Program Comprehension in Novice Programmers - Learning Activities and Learning Trajectories. Proceedings of the Working Group Reports on Innovation and Technology in Computer Science Education. +[5] Schulte, C. (2008). Block Model: an educational model of program comprehension as a tool for a scholarly approach to teaching. International Computing Education Research Workshop. +[6] Wikipedia contributors. (2022, September 28). Hermeneutics. Wikipedia, The Free Encyclopedia. https://en.wikipedia.org/w/index.php?title=Hermeneutics&oldid=1112903434 diff --git a/posts/0/linkblog-2022-12-14.gmi b/posts/1/linkblog-2022-12-14.gmi similarity index 100% rename from posts/0/linkblog-2022-12-14.gmi rename to posts/1/linkblog-2022-12-14.gmi diff --git a/posts/1/metadata.json b/posts/1/metadata.json index 17d9ba8..4135728 100644 --- a/posts/1/metadata.json +++ b/posts/1/metadata.json @@ -1,4 +1,4 @@ { - "id": "1670761332784", - "createdOn": 1670761332784 + "id": "1671026528081", + "createdOn": 1671026528081 } \ No newline at end of file diff --git a/posts/1/linkblog-2022-12-11.gmi b/posts/2/linkblog-2022-12-11.gmi similarity index 100% rename from posts/1/linkblog-2022-12-11.gmi rename to posts/2/linkblog-2022-12-11.gmi diff --git a/posts/2/metadata.json b/posts/2/metadata.json index 5a1820b..17d9ba8 100644 --- a/posts/2/metadata.json +++ b/posts/2/metadata.json @@ -1,4 +1,4 @@ { - "id": "1670625662876", - "createdOn": 1670625662876 + "id": "1670761332784", + "createdOn": 1670761332784 } \ No newline at end of file diff --git a/posts/2/more-blog-tooling.gmi b/posts/2/more-blog-tooling.gmi deleted file mode 100644 index e75534a..0000000 --- a/posts/2/more-blog-tooling.gmi +++ /dev/null @@ -1,14 +0,0 @@ -# More Blog Tooling - -I created an automation[1] to share link from pinboard[2] on here. Once I find a link I'd like to share, I add the tag `linkblog` plus my thoughts in the description field, and this script will fetch, generate a `gmi` and add it to the blog. Once it's done it replaces the tag with `linkblog-posted` so it doesn't find it next time around. - -=> https://git.sr.ht/~rbdr/pinboard-linkblog-updater [1] Pinboard Linkblog Updater -=> https://pinboard.in/ [2] Pinboard - -A problem with getting this to work is that blog[3] was just local, so I had to add some remote functionality. Now every time I add or update the blog, it will first fetch from git and push the changes. That way, I can publish content directly from the computer, and have a cron running the linkblog updater on the VPS. - -=> https://git.sr.ht/~rbdr/blog [3] Blog - -At this point I think it's worth re-evaluating how blog itself is built, as it is beginning to feel a bit clunky: When it was conceived, the project was intended to take markdown files and keep track of 3 of them so I could `rsync` them later. Now it keeps an archive as a gemlog, publishes an rss feed, allows publishing, and has remote sync: surely it's worth a rethink. - -Anyway, adding remote functionality opens up the possibility of publishing via iPad or phone, so I think I'll go work on that instead.