Make final changes to developer README

Author: haejinjo

src/README.md

@@ -1,9 +1,12 @@
-# Reactime v4 Architecture
+# Developer README
 
 ## Brief
 Our mission at Reactime is to maintain and iterate constantly, but never at the expense of future developers.<br />We know how hard it is to quickly get up to speed and onboard in a new codebase.<br />So, here are some helpful pointers to help you hit the ground running. 🏃🏾💨
 
-## Main Structure
+## Quick Tips
+- _Before_ beginning development, especially on teams, make sure to configure your linter and code formatting to conform to one unified setting (We recommend [the Airbnb style guide](https://github.com/airbnb/javascript)!) This will make reviewing PRs much more readable and less error-prone.
+
+## File Structure
 
 In the *src* folder, there are three directories we care about: *app*, *backend*, and *extension*. 
 ```
@@ -53,9 +56,26 @@ src/
     - Like regular web apps, Chrome Extensions are event-based. The background script is where one typically monitors for browser triggers (e.g. events like closing a tab, for example). The content script is what allows us to read or write to our target web application, usually as a result of [messages passed](https://developer.chrome.com/extensions/messaging) from the background script.
     - These two files help us handle requests both from the web browser and from the Reactime extension itself
 
-Still unsure about what contents scripts and background scripts do for Reactime, or for a chrome extensions in general?
-  - The implementation details [can be found](./extension/background.js) [in the files](./extension/contentScript.ts) themselves.
-  - We also encourage you to dive into [the official Chrome Developer Docs](https://developer.chrome.com/home). Some relevant sections are reproduced below:
+## Data Flow Architecture
+
+The general flow of data is described in the following steps:
+
+![demo](../assets/AppStructureDiagram.png)
+
+1. When the background bundle is loaded by the browser, it executes a script injection into the dom. (see section on *backend*). This script uses a technique called [throttle](https://medium.com/@bitupon.211/debounce-and-throttle-160affa5457b) to send state data from the app to the content script every specified milliseconds (in our case, this interval is 70ms).
+
+2. The content script always listens for messages being passed from the extension's target application. Upon receiving data from the target app, the content script will immediately forward this data to the background script which then updates an object called `tabsObj`. Each time `tabsObj` is updated, its latest version will be passed to Reactime, where it is processed for displaying to the user by the *app* folder scripts.
+
+3. Likewise, when Reactime emits an action due to user interaction -- a "jump" request for example --  a message will be passed from Reactime via the background script to the content script. Then, the content script will pass a message to the target application containing a payload that represents the state the user wants the DOM to reflect or "jump" to.
+    - One important thing to note here is that this jump action must be dispatched in the target application (i.e. *backend* land), because only there do we have direct access to the DOM.
+
+
+## Chrome Developer Resources
+Still unsure about what content scripts and background scripts do for Reactime, or for a chrome extensions in general?
+  - The implementation details [can be found](./extension/background.js) [in the source files](./extension/contentScript.ts) themselves.
+  - We also encourage you to dive into [the official Chrome Developer Docs](https://developer.chrome.com/home). 
+  
+  Some relevant sections are reproduced below:
 
 > Content scripts are files that run in the context of web pages. 
 >
@@ -79,17 +99,3 @@ Still unsure about what contents scripts and background scripts do for Reactime,
   1. The content script
   2. The chrome extension "front-end" **(*NOT* the interface of the browser, this is an important distinction.)** 
 - In other words, a background script works as a sort of middleman, directly maintaining connection with its parent extension, and acting as a proxy enabling communication between it and the content script. 
-
-
-## Data Flow
-
-The general flow of data is described in the following steps:
-
-![demo](../assets/AppStructureDiagram.png)
-
-1. When the background bundle is loaded by the browser, it executes a script injection into the dom. (see section on *backend*). This script uses a technique called [throttle](https://medium.com/@bitupon.211/debounce-and-throttle-160affa5457b) to send state data from the app to the content script every specified milliseconds (in our case, this interval is 70ms).
-
-2. The content script always listens for messages being passed from the extension's target application. Upon receiving data from the target app, the content script will immediately forward this data to the background script which then updates an object called `tabsObj`. Each time `tabsObj` is updated, its latest version will be passed to Reactime, where it is processed for displaying to the user by the *app* folder scripts.
-
-3. Likewise, when Reactime emits an action due to user interaction -- a "jump" request for example --  a message will be passed from Reactime via the background script to the content script. Then, the content script will pass a message to the target application containing a payload that represents the state the user wants the DOM to reflect or "jump" to.
-    - One important thing to note here is that this jump action must be dispatched in the target application (i.e. *backend* land), because only there do we have direct access to the DOM.