diff --git a/src/c-tips/index.md b/src/c-tips/index.md
index 14d7eeaa..217f6286 100644
--- a/src/c-tips/index.md
+++ b/src/c-tips/index.md
@@ -6,7 +6,7 @@ highlight how things you might already be used to in C are different in Rust.
 
 ## Preprocessor
 
-In embedded C it is very common to use the preprocessor for a varity of
+In embedded C it is very common to use the preprocessor for a variety of
 purposes, such as:
 
 * Compile-time selection of code blocks with `#ifdef`
@@ -52,7 +52,7 @@ pub mod iir;
 ```
 
 You can similarly include code blocks only if a feature is _not_ enabled, or if
-any combination or features is or is not enabled.
+any combination of features are or are not enabled.
 
 Additionally, Rust provides a number of automatically-set conditions you can
 use, such as `target_arch` to select different code based on architecture. For
@@ -62,7 +62,7 @@ full details of the conditional compilation support, refer to the
 [conditional compilation]: https://doc.rust-lang.org/reference/conditional-compilation.html
 
 The conditional compilation will only apply to the next statement or block. If
-a block can not be used in the current scope then then `cfg` attribute will
+a block can not be used in the current scope then the `cfg` attribute will
 need to be used multiple times.  It's worth noting that most of the time it is
 better to simply include all the code and allow the compiler to remove dead
 code when optimising: it's simpler for you and your users, and in general the
diff --git a/src/unsorted/speed-vs-size.md b/src/unsorted/speed-vs-size.md
index 9b123be1..3a42fdad 100644
--- a/src/unsorted/speed-vs-size.md
+++ b/src/unsorted/speed-vs-size.md
@@ -1,8 +1,8 @@
 # Optimizations: the speed size tradeoff
 
 Everyone wants their program to be super fast and super small but it's usually
-not possible to have maximize both characteristics. This section discusses the
-different optimization levels that `rustc` provides and how the affect the
+not possible to have both characteristics. This section discusses the
+different optimization levels that `rustc` provides and how they affect the
 execution time and binary size of a program.
 
 ## No optimizations
@@ -25,7 +25,7 @@ debug = true
 
 No optimizations is great for debugging because stepping through the code feels
 like you are executing the program statement by statement, plus you can `print`
-stack variables and function arguments in GDB. When the code is optimized trying
+stack variables and function arguments in GDB. When the code is optimized, trying
 to print variables results in `$0 = <value optimized out>` being printed.
 
 The biggest downside of the `dev` profile is that the resulting binary will be
@@ -33,7 +33,7 @@ huge and slow. The size is usually more of a problem because unoptimized
 binaries can occupy dozens of KiB of Flash, which your target device may not
 have -- the result: your unoptimized binary doesn't fit in your device!
 
-Can we have smaller debugger friendly binaries? Yes, there's a trick.
+Can we have smaller, debugger friendly binaries? Yes, there's a trick.
 
 ### Optimizing dependencies
 
@@ -117,7 +117,7 @@ profile which defaults to `opt-level = 3`.
 
 Both `opt-level = 2` and `3` optimize for speed at the expense of binary size,
 but level `3` does more vectorization and inlining than level `2`. In
-particular, you'll see that at `opt-level` equal or greater than `2` LLVM will
+particular, you'll see that at `opt-level` equal to or greater than `2` LLVM will
 unroll loops. Loop unrolling has a rather high cost in terms of Flash / ROM
 (e.g. from 26 bytes to 194 for a zero this array loop) but can also halve the
 execution time given the right conditions (e.g. number of iterations is big