Update src/content/drafts/code-review-nit-to-ecosystem-improvements.md

Co-authored-by: Nicholas C. Zakas <[email protected]>

src/content/drafts/code-review-nit-to-ecosystem-improvements.md

@@ -20,7 +20,7 @@ To answer these questions, it helps to review the timeline of events.
 
 ## Timeline
 
-* May 2020: I was reviewing a diff/PR at work that made a nullable value non-nullable and noticed that the author had left behind an if condition that handled the now impossible case where the value was null. I started to wonder why Flow hadn’t automatically pointed that out.
+* **May 2020:** I was reviewing a pull request at work that made a nullable value non-nullable. I noticed that the author had left behind an `if` condition that handled the now impossible case where the value was `null`. I started to wonder why Flow hadn’t automatically pointed that out.
 * **May 2020:** I posted to an internal group asking the Flow team about it. The answer was that Flow, like TypeScript, is not sound. For example `arr[x]` is typed as non-nullable but might actually be undefined at runtime. Flow had implemented these checks in the past, but they caused major issues by telling people their null checks were safe to remove when they were not, so they removed the checks. [Brad Zacher](https://zacher.com.au/) happened to see the post and chimed in with an observation that a syntactic approach, rather than a type based one, could be safe even if it was less powerful.
 * Aug. 2020: I implemented the syntactic validation approach as an internal ESLint rule, and realized it generalized beyond null checks to all constant comparisons. I ran it in Meta’s mono-repo and found it identified several hundred existing bugs.
 * Oct. 2020: Brad Zacher suggested I propose it as a new core rule in ESLint. [I did](https://github.com/eslint/eslint/issues/13752), and they [liked the idea](https://github.com/eslint/eslint/issues/13752#issuecomment-729125654).