The point made in the article is based on an example that violates good Separation of Concerns. Also focusing on why induces developers to justify themselves th

The point made in the article is based on an example that violates good Separation of Concerns. Also focusing on why induces developers to justify themselves the reasons to write the code and assume any reader knows all the assumptions of the environment. This trend will strongly disencourage code exploration and keeps newcomers in the outer side of the wall. A good alternative would be to have a combination of 1. good separation of concerns 2. good method/function name and 3 comment with focus on what. If you do this consistently your app would be really friendly to newcomers and even to your future self because when taking a look to it 2 years later, your code will tell you the name of an action followed by a human description of what it does without forcing you to read the rest of the code and reverse engineer it to answer what it should be a simple question. Also you scan code through the app faster if you need to read less to understand what's all about. Most people don't see this because they are too immersed in the set of assumptions that a given project has, but time proves they would be rather focusing on what. There is a secondary benefit on doing this, it will slowly make you write better method and argument names, so it will me more often than not that your code will need comments at all.