diff --git a/TODO b/TODO
index 503b1ad..061b48c 100644
--- a/TODO
+++ b/TODO
@@ -11,7 +11,9 @@
   - cache line explanation: http://mechanitis.blogspot.com/2011/07/dissecting-disruptor-why-its-so-fast_22.html
   - avoiding false sharing: http://www.drdobbs.com/parallel/eliminate-false-sharing/217500206
   - how does this translate to go? http://www.catb.org/esr/structure-packing/
-
+  - https://en.wikipedia.org/wiki/Amdahl%27s_law
+  - https://github.com/ardanlabs/gotraining/tree/master/topics/profiling
+  - https://github.com/ardanlabs/gotraining/tree/master/topics/benchmarking
 
 videos:
     https://gophervids.appspot.com/#tags=optimization
@@ -40,6 +42,11 @@ videos:
     Machine Architecture: Things Your Programming Language Never Told You
     https://www.youtube.com/watch?v=L7zSU9HI-6I
 
+asm:
+    https://golang.org/doc/asm
+    https://goroutines.com/asm
+    http://www.doxsey.net/blog/go-and-assembly
+
 posts:
     http://www.eecs.berkeley.edu/~rcs/research/interactive_latency.html
     https://arxiv.org/abs/1509.05053
diff --git a/performance.md b/performance.md
index 45bb4ab..dd2befe 100644
--- a/performance.md
+++ b/performance.md
@@ -6,6 +6,8 @@ format where the content is here instead of external.  The links should be sorte
 
 All the content will be licensed under CC-BY-SA.
 
+## Optimization Workflow
+
 * All optimizations should follow these steps:
 
     1. determine your performance goals and confirm you are not meeting them
@@ -20,8 +22,10 @@ All the content will be licensed under CC-BY-SA.
     1. use <https://github.com/tsenart/vegeta> for load testing http services
     1. make sure your latency numbers make sense: <https://youtu.be/lJ8ydIuPFeU>
 
-Step 0 is important.  It tells you when and where to start optimizing.  More
-importantly, it also tells you when to stop.
+The first step is important. It tells you when and where to start optimizing.
+More importantly, it also tells you when to stop.  Pretty much all
+optimizations add code complexity in exchange for speed.  And you can *always*
+make code faster.  It's a balancing act.
 
 The basic rules of the game are:
 
@@ -37,6 +41,7 @@ The basic rules of the game are:
 Techniques applicable to source code in general
 
 1. introduction to pprof
+ * (micro)benchmarks
  * -cpuprofile
  * net/http/pprof
   * go tool pprof (and <https://github.com/google/pprof>)
@@ -72,7 +77,7 @@ Techniques applicable to source code in general
 * And all the dangers that go with it
 * Common uses for unsafe
 * mmap'ing data files
-* serialization
+* speedy de-serialization
 
 ## Assembly
 * Stuff about writing assembly code for Go
@@ -82,9 +87,10 @@ Techniques applicable to source code in general
   * encoding/json -> ffjson
   * net/http -> fasthttp
   * regexp -> ragel (or other regular expression package)
-  * encoding/gob -> <https://github.com/alecthomas/go_serialization_benchmarks>
-  * protobuf -> <https://github.com/gogo/protobuf>
-  * serialization is all about tradeoffs
+  * serialization
+      * encoding/gob -> <https://github.com/alecthomas/go_serialization_benchmarks>
+      * protobuf -> <https://github.com/gogo/protobuf>
+      * all formats have trade-offs; choose one that matches what you need
 
 ## Tooling