diff --git a/ez-template-docs/tutorials/slew_constants.md b/ez-template-docs/tutorials/slew_constants.md
index a82fd1c..df4b4d5 100644
--- a/ez-template-docs/tutorials/slew_constants.md
+++ b/ez-template-docs/tutorials/slew_constants.md
@@ -12,13 +12,24 @@ Most robots will work perfectly fine without slew.  You can visit this page if
 ## What is it?
 Slew is when your motors start at a lower speed and build up to a faster speed.  This can be useful if your robot is prone to tipping, can wheelie easily, or is prone to wheel slip at the start of motions.   
 
+EZ-Template treats the output of slew as a **maximum speed** the PID can output.  The output of slew does **not** get set to the motors.  If slew is enabled for an extremely small motion, it is very likely that slew will not do anything and your motion will still be as fast as possible.  
+
 ## Tuning Slew 
 There are 2 parameters to tune with slew in EZ-Template; the distance to slew for and starting speed.  The robot will accelerate very quickly with a low distance to slew for, regardless of the starting speed.  
 
+There are 2 parameters to tune in EZ-Template.
+* Distance to slew for
+  * The larger this number is, the longer it will take to reach your maximum speed.  Making this number smaller will cause the robot to accelerate quickly. 
+* Starting speed
+  * The smaller this number is, the slower the robot will start motions.  Making this number smaller will cause the robot to accelerate slowly.  
+
+There is a push and pull balance between these two variables and you have to find the middle ground.  
+
 I will tune slew by running normal motions but having the robot go slower.  The goal is to find the fastest the robot can go without any of the undesirable behaviors described above.  To enable slew you need the `true` parameter at the end of your `x_pid_set()`.  
 ```cpp
 void tuning_slew() {
   chassis.drive_pid_set(24_in, 80, true);
+  chassis.pid_wait();
 }
 ```
 
@@ -35,10 +46,10 @@ Now you can lower the distance until the robot is able to successfully reach `DR
 ```cpp
 void tuning_slew() {
   chassis.drive_pid_set(24_in, DRIVE_SPEED, true);
+  chassis.pid_wait();
 }
 ```
 
-## Specifics for Each Motion
 
 ### Driving
 Sometimes robots aren't symmetrical and can be tippier in one direction than the other.  This can be solved by choosing one of the following functions to place in `default_constants()`.  
diff --git a/ez-template-docs/tutorials/tuning_exit_conditions.md b/ez-template-docs/tutorials/tuning_exit_conditions.md
index a5c2be1..ab38fb4 100644
--- a/ez-template-docs/tutorials/tuning_exit_conditions.md
+++ b/ez-template-docs/tutorials/tuning_exit_conditions.md
@@ -31,7 +31,7 @@ EZ-Template's exit conditions are a little more special than that though.  We r
 You can add another layer to this where it'll also check for a larger area.  Now 2 timers will run, one when you're within X of target and one when you're within Y of target.     
 ![](images/big_timeout.gif) 
 
-But when the robot enters the smaller exit zone, the big timer will not continue.  This can be seen here.     
+But when the robot enters the smaller exit zone, the big timer will not continue.  If the big timer was not reset to 0 and we overshot target, big timer would be starting from a very high number and we would exit before correctly confirming the robot has settled.  This can be seen here.     
 ![](images/big_timeout_reset_small_timeout.gif) 
 
 There are 2 more timers that you can add on as well.  These are intended to be **failsafes** for when the previous two don't trigger fast enough or don't trigger at all.  One timer will start to increase when the velocity of the robot is 0, so if the robot is still for too long it'll exit.  Another timer will start once the robot sees it's pulling on the motors too hard (ie, you're fighting your opponent for a mobile goal), and if it's doing this for too long it'll exit.  
@@ -67,12 +67,14 @@ chassis.pid_wait_until(24);
 ```
 
 ### pid_wait_quick_chain()
-`pid_wait_quick_chain()` is your fastest way of exiting.  The code below is what happens internally.  You will tell the robot to go 24 inches, internally X will get added to target, and `pid_wait_until()` will get called with the target YOU entered.  While being the fastest way of exiting, this should be used with caution as it can lead to inconsistencies.  Make sure your PID is well-tuned and do enough testing that you're confident your results are consistent.   
+`pid_wait_quick_chain()` is your fastest way of exiting.  The code below is what happens internally.  You will tell the robot to go 24 inches, internally X will get added to target, and `pid_wait_until()` will get called with the target YOU entered.  The code below is what happens for you internally.   
 ```cpp
 chassis.pid_drive_set(27_in, 110);  // You really want to go 24in
 chassis.pid_wait_until(24);
 ```
 
+While being the fastest way of exiting, this should be used carefully to avoid inconsistencies.  Make sure your PID is well-tuned and do enough testing that you're confident your results are consistent.  
+
 ## Tuning
 Ultimately you're tuning for 2 functions; timers and when to start timing for `pid_wait()`, and how much to add to target for `pid_wait_quick_chain()`.  
 
@@ -99,7 +101,11 @@ The default constants are already pretty aggressive, you shouldn't have to tune
 You should make these numbers as low as you can without causing inconsistencies.  With `pid_wait()` you generally want the robot to be pretty close to stopped before it moves on to the next motion.  
 
 ### Tuning pid_wait_quick_chain()
-You can tune the amount added to `target` during chained motions.  If this number is too large, you'll carry too much momentum into the next motion and will cause inconsistencies.  The only downside to this number being too small is potential wasted time as it could turn into a normal `pid_wait()` if you don't overshoot your target.  Generally, I would err on this being smaller.  
+You can tune the amount added to `target` during chained motions.  
+
+**Larger constants** will carry more momentum into the next motion, making your autonomous faster but potentially hurting consistency.  **Smaller constants** will carry less momentum into the next motion, this will still be significantly faster then any other method of exiting but could be slightly less consistent than `pid_wait()`.  
+
+If I were making autonomous routines, I would try to use a smaller constant for normal motions and only push a larger constant when an autonomous routine would greatly bennifit from it.  
 
 
 #### Driving