|
> If this is not abundantly clear to you, consider how clarity shapes your interaction with lawyers, doctors and mechanics. I have a bunch of friends who are or have been mechanics and technicians. They, and others I have interacted with are actually quite good at explaining things in layman's terms. Doctors are quite similar in that regard. It's an important part of their job to do so. With lawyers I had fewer interactions, they tend to produce terrible texts (contracts, licences, ToCs etc.) but they can explain things typically well enough for one to understand their advice. And going back to the article I think the problem statement is important. But the solution is only half-way there. If you can afford to be less technical when interacting with others, then yes, do so. But given a large enough project and people you are building up knowledge about the thing your building and that needs terms (a mini language) that foster shared understanding. Those terms are often used across the code, data, UI, email, version control, chat and most importantly a spec or any document that describes the most important terms and their functionality. All involved sides should be learning form each other and build up a common language. It's a two way street and it should be deliberate. It can be a small thing and still be super useful. |