diff --git a/README.md b/README.md
index 3f902fb..2c0801d 100644
--- a/README.md
+++ b/README.md
@@ -158,7 +158,7 @@ I once consulted a startup where a team of three developers introduced 17(!) mic
 
 Is this the right way to approach the uncertainty of a new system? It's enormously difficult to elicit the right logical boundaries in the beginning, and by introducing too many microservices we make things worse. The team's only justification was: "The F(M)AANG companies proved microservices architecture to be effective". *Hello, you got to stop dreaming big.*
 
-Checkout the [Tanenbaum–Torvalds debate](https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate). The claim suggested that Linux's monolithic design was flawed and obsolete, and that a microkernel architecture should be used instead. Indeed, the microkernel design seemed to be superior "from a theoretical and aesthetical" point of view. Three decades on, microkernel-based GNU Hurd is still in development, and monolithic Linux is everywhere - this page is powered by Linux, your smart teapot is powered by Linux.  
+The [Tanenbaum-Torvalds debate](https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate) argued that Linux's monolithic design was flawed and obsolete, and that a microkernel architecture should be used instead. Indeed, the microkernel design seemed to be superior "from a theoretical and aesthetical" point of view. Three decades on, microkernel-based GNU Hurd is still in development, and monolithic Linux is everywhere - this page is powered by Linux, your smart teapot is powered by Linux.  
 
 A well-crafted monolith with truly isolated modules is often much more flexible than a bunch of microservices. It also requires far less cognitive effort to maintain. It's only when the need for separate deployments becomes crucial (e.g. development team scaling) that you should consider adding a network layer between the modules (future microservices).