diff --git a/_posts/2018-04-17-dolls-and-maquettes.markdown b/_posts/2018-04-17-dolls-and-maquettes.markdown
index ca38094..c5dd7d1 100644
--- a/_posts/2018-04-17-dolls-and-maquettes.markdown
+++ b/_posts/2018-04-17-dolls-and-maquettes.markdown
@@ -33,7 +33,7 @@ But why can't *they* work for us? Why can't we design them so they *move*, thus
 
 Here is how I see it: an engineer and a software developer are given the same task: they each have to build a ``Car``. The engineer will build a real ``Car`` which will actually move, accelerate etc. On the other hand, the software developer will just look at the requirement, cast a model of a ``Car`` and then proceed to build all sorts of tools *around* that model, that should make it move and gain some speed... I personally imagine a room filled with beams and strings attached to the lifeless model. Also, there would probably be a lever that would have to be operated by someone in order for the "car" to do something -- all those beams, strings and the lever are the helper methods and service classes from an application's code.
 
-The software engineer did not actually build a ``Car``, because he didn't understand the principles applied by the engineer, which are: abstraction, encapsulation, decoupling, cohesion etc. Object orientation was supposed to take the principles used by the engineer and bring them in the coding/software development realm. However, thinking in a procedural manner, our developer merely managed to make the maquette of a ``Car`` somewhat behave like a real one - even if the developer managed to follow all the ``clean code`` recommandations, his/her final work would still not be a real car: it would still be a lifeless model "operated" by some beams and strings, just maybe with some good cable/beam management.
+The software developer did not actually build a ``Car``, because he didn't understand the principles applied by the engineer, which are: abstraction, encapsulation, decoupling, cohesion etc. Object orientation was supposed to take the principles used by the engineer and bring them in the coding/software development realm. However, thinking in a procedural manner, our developer merely managed to make the maquette of a ``Car`` somewhat behave like a real one - even if the developer managed to follow all the ``clean code`` recommandations, his/her final work would still not be a real car: it would still be a lifeless model "operated" by some beams and strings, just maybe with some good cable/beam management.
 
 The comparison may sound crazy but that's what it is: instead of teaching them real, practical engineering principles, mainstream OOP just gave people the tools necessary to put a label on their data while letting them maintain their procedural way of thinking. Instead, real object orientation is a complete switch of mindset: you go from the position of the manual worker to the position of the engineer who designs objects that actually solve issues, automate things.