diff --git a/docs/FAQs/DoINeedReFrame.md b/docs/FAQs/DoINeedReFrame.md
index aa83dd5..3ad7e8b 100644
--- a/docs/FAQs/DoINeedReFrame.md
+++ b/docs/FAQs/DoINeedReFrame.md
@@ -12,7 +12,7 @@ But it only supplies the V part of the traditional MVC triad. When
 your application gets bigger and more complicated, you'll need to 
 find solutions to questions in the M and C realms. Questions like "where do I put control logic?".
 And, "how do I manage state?".  And, "How do I put up a spinner
-when waiting for CPU intensive computations to run, while allowing the user to press Cancel?"  
+when waiting for CPU intensive computations to run, while allowing the user to press Cancel?"
 How do I ensure efficient view updates?  How do I write my control logic in a way that's testable? 
 How should new websocket packets be communicated with the broader app? Or GET failures? 
 
@@ -36,9 +36,9 @@ Now, in response, some will enthusiastically say "yes, I want to grow my own
 architecture. I like mine!". Fair enough - its a fun ride!
 
 I think problems arise when this process is not conscious and purposeful. You 
-can accelerate quickly with Reagent and get a bunch of enjoyable early wins, but then  
-ultimately end up off the road, in the paddock, because of
-one of the corners leading up to a bigger application.
+can accelerate quickly with Reagent and get a bunch of enjoyable early wins, but then
+ultimately end up off the road, in the paddock, because of the twists and turns 
+leading up to a bigger application.
 
 I've had many people (20?) privately say to me that's what happened to them. The real
 number would obviously be much higher. And that's pretty much the reason for