summaryrefslogtreecommitdiff
path: root/tutorials/module_2
diff options
context:
space:
mode:
authorChristian Kolset <christian.kolset@gmail.com>2025-04-30 09:12:41 -0600
committerChristian Kolset <christian.kolset@gmail.com>2025-04-30 09:12:41 -0600
commitc92bce22a096db9275756628613317998b083359 (patch)
treed54e1394fa846d75037abb8383713c763c82a592 /tutorials/module_2
parenteb2830349fd1892ec68659c22bab73f26255e268 (diff)
Updated book pdf
Diffstat (limited to 'tutorials/module_2')
-rw-r--r--tutorials/module_2/documentation.md2
1 files changed, 2 insertions, 0 deletions
diff --git a/tutorials/module_2/documentation.md b/tutorials/module_2/documentation.md
index 817914a..984c404 100644
--- a/tutorials/module_2/documentation.md
+++ b/tutorials/module_2/documentation.md
@@ -9,7 +9,9 @@ When documenting a project, it's essential to include detailed notes that captur
## Explain Your Decisions
In programming, there are often several valid approaches to solving a problem. When documenting your code, it's important to clarify why you chose a particular method—especially if it deviates from common practices. Anticipating potential questions and addressing them directly in your documentation helps others follow your reasoning and builds trust in your solution.
+
![Rubber duck debugging technique](figures/rubberDuck.png)
+
A useful strategy for articulating these decisions is the "rubber duck" technique—explaining your code as if you're teaching it to someone else. Whether spoken aloud or written down, this practice helps you clarify your logic and communicate the reasoning behind your choices, providing valuable context for future collaborators or reviewers.​
## Include a README