diff --git a/doc/api/worker_threads.md b/doc/api/worker_threads.md
index 82fb46e017689c..5cc74e1bc94ef7 100644
--- a/doc/api/worker_threads.md
+++ b/doc/api/worker_threads.md
@@ -4,21 +4,20 @@
 
 > Stability: 1 - Experimental
 
-The `worker` module provides a way to create multiple environments running
-on independent threads, and to create message channels between them. It
-can be accessed using:
+The `worker_threads` module enables the use of threads with message channels
+between them. To access it:
 
 ```js
 const worker = require('worker_threads');
 ```
 
-Workers are useful for performing CPU-intensive JavaScript operations; do not
-use them for I/O, since Node.js’s built-in mechanisms for performing operations
-asynchronously already treat it more efficiently than Worker threads can.
+Workers (threads) are useful for performing CPU-intensive JavaScript operations.
+They will not help much with I/O-intensive work. Node.js’s built-in asynchronous
+I/O operations are more efficient than Workers can be.
 
-Workers, unlike child processes or when using the `cluster` module, can also
-share memory efficiently by transferring `ArrayBuffer` instances or sharing
-`SharedArrayBuffer` instances between them.
+Unlike `child_process` or `cluster`, `worker_threads` can share memory. They do
+so by transferring `ArrayBuffer` instances or sharing `SharedArrayBuffer`
+instances.
 
 ```js
 const {
@@ -46,10 +45,9 @@ if (isMainThread) {
 }
 ```
 
-Note that this example spawns a Worker thread for each `parse` call.
-In practice, it is strongly recommended to use a pool of Workers for these
-kinds of tasks, since the overhead of creating Workers would likely exceed the
-benefit of handing the work off to it.
+The above example spawns a Worker thread for each `parse()` call. In actual
+practice, use a pool of Workers instead for these kinds of tasks. Otherwise, the
+overhead of creating Workers would likely exceed their benefit.
 
 ## worker.isMainThread
 <!-- YAML