And I guess this is exactly why author wants programmers to learn from the masters of spoken langauges-- ability to use the right word(s) to explain the concept/abstraction/property/behaviour/type.
If one is unsure about how something works, then more often than not one would end up naming the thing wrong. By far and large, the most frustrating thing I've come across during code-reviews is generic names assigned to vars like 'buffer', 'arrays', 'queues' and so on... and SQL table names that have no relevance to the data being stored in them. It is a constant struggle to read and reason with such constructs. So if you know how something works, you are oblidged to name it approp.
Douglas Crockford in his 'JS: The Better Parts' talk at JSConf 2014 spoke about three responsibilities a developer must have:
1. Make life of people using the software better and to not frustrate them, humiliate them, hurt them, confuse them.
2. Make life of people maintaining/developing the software better . To not check-in cruft, bloat, and errors. Write the best code, and to not make anything worse.
3. Make life of people managing the business/development easier.
What does "Make life of" mean? As a native English speaker, I don't understand it; I presume it means "Make life better for", though the closest we have in English is probably "Make light of", which means something completely different (and is slightly funny in this context).
He means "Make the life of people..." in each case. The phrasing without "the" sounds to me like Powerpoint-Speak... leaving out minor words in order to fit more bullets onto a slide. Those minor words are usually grammatically necessary, but in the context of a slide presentation the presenter's verbal part of the presentation clarifies ambiguities in the visual part.
And I guess this is exactly why author wants programmers to learn from the masters of spoken langauges-- ability to use the right word(s) to explain the concept/abstraction/property/behaviour/type.
If one is unsure about how something works, then more often than not one would end up naming the thing wrong. By far and large, the most frustrating thing I've come across during code-reviews is generic names assigned to vars like 'buffer', 'arrays', 'queues' and so on... and SQL table names that have no relevance to the data being stored in them. It is a constant struggle to read and reason with such constructs. So if you know how something works, you are oblidged to name it approp.
Douglas Crockford in his 'JS: The Better Parts' talk at JSConf 2014 spoke about three responsibilities a developer must have:
1. Make life of people using the software better and to not frustrate them, humiliate them, hurt them, confuse them.
2. Make life of people maintaining/developing the software better . To not check-in cruft, bloat, and errors. Write the best code, and to not make anything worse.
3. Make life of people managing the business/development easier.