diff --git a/reactivity-graph.Rmd b/reactivity-graph.Rmd
index 0e82666b..90f678d3 100644
--- a/reactivity-graph.Rmd
+++ b/reactivity-graph.Rmd
@@ -200,7 +200,7 @@ The arrows coming out of a node are one-shot notifications that will fire the *n
 Now that they've fired, they've fulfilled their purpose and we can erase them.
 
 It's less obvious why we erase the arrows coming *in* to an invalidated node, even if the node they're coming from isn't invalidated.
-While those arrows represent notifications that haven't fired, the invalidated node no longer cares about them: reactive consumers only care about notifications in order to invalidate themselves and that that has already happened.
+While those arrows represent notifications that haven't fired, the invalidated node no longer cares about them: reactive consumers only care about notifications in order to invalidate themselves and that has already happened.
 
 It may seem perverse that we put so much value on those relationships, and now we've thrown them away!
 But this is a key part of Shiny's reactive programming model: though these particular arrows *were* important, they are now out of date.
@@ -271,8 +271,8 @@ The neat thing about this process is that Shiny has done the minimum amount of w
 
 ## Dynamism
 
-In Section \@ref(removing-relationships), you learned that Shiny "forgets" the connections between reactive components that it spend so much effort recording.
-This makes Shiny's reactive reactive dynamic, because it can change while your app runs.
+In Section \@ref(removing-relationships), you learned that Shiny "forgets" the connections between reactive components that it spent so much effort recording.
+This makes Shiny's reactivity dynamic, because it can change while your app runs.
 This dynamism is so important that I want to reinforce it with a simple example:
 
 ```{r}