diff --git a/README.md b/README.md
index 7dd5096..6447740 100644
--- a/README.md
+++ b/README.md
@@ -9,7 +9,7 @@ the state pattern is a pattern that aims to get rid of the mess that a state mac
 
 the power button does what it says either turns the phone off or on, the lock button too does what it says on the tin locks the phone, lastly the string enter button enters what every string is in the phones buffer this is used for entering things like passwords to unlock the phone.
 
-using these buttons you determin you need 4 states for your phone these are:
+using these buttons you determine you need 4 states for your phone these are:
 - off
 - unlock
 - locked
@@ -48,10 +48,15 @@ str=x : string enter button press with string x
 ----------- \ state diagram -----------
 ```
 
-now you may read these requirements for the device and think ill just implement this with a state machine how bad can it be. Well your tech lead tells you that this systems needs to scaled to over 100 different states as they make the system more complex. you ask him "why do we need this" they reply back with managment said so. And so between the idea of getting fired from throwing a brick at the managment team and implementing this state diagram you decide you need this job and to implement state pattern.
-this pattern allows for greater flexablity when creating new states since you dont have to add to an ever growning state machine (lets do some simple math if we assume that you end up with 100 states in the end and each state takes up 20 odd line that would be a 2k line state machine and a nightmare to debug (i should know ive seen them in the wild))
+now you may read these requirements for the device and think ill just implement this with a state machine how bad can it be. Well your tech lead tells you that this systems needs to scaled to over 100 different states as they make the system more complex. you ask him "why do we need this" they reply back with management said so. And so between the idea of getting fired from throwing a brick at the management team and implementing this state diagram you decide you need this job and to implement state pattern.
+this pattern allows for greater flexibility when creating new states, since you dont have to add to an ever gowning state machine. we do some simple math to see how out of hand this can get, 
+if we assume that you end up with 100 states in the end and each state takes up 20 odd line 
+$$
+100_{\text{states}} \times 20_{\text{loc}} = 2000_{\text{loc}}
+$$
+that would be a 2k line state machine and a nightmare to debug (i should know ive seen them in the wild)
 
-so to start implement this pattern we first draw up a uml diagram of how it should go togeather. we can see we have the device itself and which is composed of a device state that has the pointer to the device that it is in
+so to start implement this pattern we first draw up a uml diagram of how it should go together. we can see we have the device itself and which is composed of a device state that has the pointer to the device that it is in
 
 ```mermaid
 classDiagram
@@ -86,9 +91,9 @@ classDiagram
 
 
 so to implement this we will first create a struct for the device well call this [Device_t](/src/device.h#L67) this device holds its current state ([DeviceState_s](/src/device.h#L52)) and the string that was entered. The [DeviceState_s](/src/device.h#L52) actually holds all the [functions](/src/device.h#L34) or [methods](/src/device.h#L34) that this device uses, with the pressPwrButton, pressStrInputButton, and pressLockButton methods just being alias to these methods as can be seen in [device.c](/src/device.c). these method are defined within the [DeviceInterface_t](/src/device.h#L34) struct which really just acts as a [vtable](https://en.wikipedia.org/wiki/Virtual_method_table) for the given inputs (power button, lock button, string enter button) that will effect the device.
-This whole interface allows for the underlying state to change with out having to use differnt function calls depending on the current state.
+This whole interface allows for the underlying state to change with out having to use different function calls depending on the current state.
 
-now to actually create the meat of this device the logic that changes the state, to do this we will first create a [header file](/src/states/state.h) to store all the functions that change the state of the device. now we will implement and state so we will start [off state](/src/states/off_state.c) with the easest one the off state (no bother having the rest if the device cant turn on). to create this state we will implement the functions that are defined within the [interface](/src/device.h#L34) we created, this functions will define what happens to the current state based on the given input. so `pressPwrMethod` is what happens when the power button is pressed when its in the off state (to make the code [grep-able](https://morizbuesing.com/blog/greppability-code-metric/) these functions should probably be prefixed with the given state like `OffStatePressPwrMethod`). these function are prefix with the static keyword as they should only ever be used here and not exposed. the other methods should be self explanatory. lastly we must implement the function that actually changes the state of the device to this given state, so to change the state we just set the devices state to a new struct with the given methods that we defined within this file.
+now to actually create the meat of this device the logic that changes the state, to do this we will first create a [header file](/src/states/state.h) to store all the functions that change the state of the device. now we will implement and state so we will start [off state](/src/states/off_state.c) with the easiest one the off state (no bother having the rest if the device cant turn on). to create this state we will implement the functions that are defined within the [interface](/src/device.h#L34) we created, this functions will define what happens to the current state based on the given input. so `pressPwrMethod` is what happens when the power button is pressed when its in the off state (to make the code [grep-able](https://morizbuesing.com/blog/greppability-code-metric/) these functions should probably be prefixed with the given state like `OffStatePressPwrMethod`). these function are prefix with the static keyword as they should only ever be used here and not exposed. the other methods should be self explanatory. lastly we must implement the function that actually changes the state of the device to this given state, so to change the state we just set the devices state to a new struct with the given methods that we defined within this file.
 
 ```c
 
@@ -124,7 +129,7 @@ void setDeviceStateToOff(Device_t *device) {
 ```
 and finally we expose the set method in our [header file](/src/states/state.h) so the other states can set to this state. next we just implement the rest of the state Lock, Unlock, and Debug and can finally test our creation in [`main.c`](/src/main.c).
 
-now that you have implement this basic state pattern your tech lead comes to you and tells you to implement one more state then they will let you throw a brick at managment as a treat this state is:
+now that you have implement this basic state pattern your tech lead comes to you and tells you to implement one more state then they will let you throw a brick at management as a treat this state is:
 - A calling state where:
     - when the phone is unlocked you can type in a number in the the string input and it will call it
     - you can also turn off the phone from this state
@@ -149,4 +154,4 @@ to build run these command in the root of the project:
 > ./build/main 
 
 ```
-and if you have a differnt complier you want to use that is posix compliant just change the `CC` macro in the `nob.c` with your one.
\ No newline at end of file
+and if you have a different compiler you want to use that is posix compliant just change the `CC` macro in the `nob.c` with your one.
\ No newline at end of file