]> git.r.bdr.sh - rbdr/blog.unlimited.pizza/commitdiff
blog-sync-up-1671315215521
authorRuben Beltran del Rio <redacted>
Sat, 17 Dec 2022 22:13:35 +0000 (23:13 +0100)
committerRuben Beltran del Rio <redacted>
Sat, 17 Dec 2022 22:13:35 +0000 (23:13 +0100)
archive/1671315215263/metadata.json [new file with mode: 0644]
archive/1671315215263/reading-hermeneutics-and-the-block-model.gmi [new file with mode: 0644]
posts/0/metadata.json
posts/0/reading-hermeneutics-and-the-block-model.gmi [new file with mode: 0644]
posts/1/linkblog-2022-12-14.gmi [moved from posts/0/linkblog-2022-12-14.gmi with 100% similarity]
posts/1/metadata.json
posts/2/linkblog-2022-12-11.gmi [moved from posts/1/linkblog-2022-12-11.gmi with 100% similarity]
posts/2/metadata.json
posts/2/more-blog-tooling.gmi [deleted file]

diff --git a/archive/1671315215263/metadata.json b/archive/1671315215263/metadata.json
new file mode 100644 (file)
index 0000000..6d86ee5
--- /dev/null
@@ -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 (file)
index 0000000..fd9c48d
--- /dev/null
@@ -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
index 41357283e3dbd7eb92301320f9b889c906988af2..6d86ee58cf4117a4c7ca10330d7e5ef4c5dad72f 100644 (file)
@@ -1,4 +1,4 @@
 {
 {
-  "id": "1671026528081",
-  "createdOn": 1671026528081
+  "id": "1671315215263",
+  "createdOn": 1671315215263
 }
\ No newline at end of file
 }
\ 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 (file)
index 0000000..fd9c48d
--- /dev/null
@@ -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
index 17d9ba84fde70fbb159d4ee77d4c7c94638ed14f..41357283e3dbd7eb92301320f9b889c906988af2 100644 (file)
@@ -1,4 +1,4 @@
 {
 {
-  "id": "1670761332784",
-  "createdOn": 1670761332784
+  "id": "1671026528081",
+  "createdOn": 1671026528081
 }
\ No newline at end of file
 }
\ No newline at end of file
index 5a1820b2a807400f9f99e91e5c3b66b09f038b5d..17d9ba84fde70fbb159d4ee77d4c7c94638ed14f 100644 (file)
@@ -1,4 +1,4 @@
 {
 {
-  "id": "1670625662876",
-  "createdOn": 1670625662876
+  "id": "1670761332784",
+  "createdOn": 1670761332784
 }
\ No newline at end of file
 }
\ 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 (file)
index e75534a..0000000
+++ /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.