4 ms·
Slide 41: "If you don't know what a thing should be called, you cannot know what it is. If you don't know what it is, you cannot sit down and write the code."
by dkersten 11y ago
Slide 41: "If you don't know what a thing should be called, you cannot know what it is. If you don't know what it is, you cannot sit down and write the code."
A few years ago, I programmed in Max/MSP (max4live, technically) for a while and one thing I found super-refreshing is the ease at which you could prototype and experiment your way to a solution just by not having to figure out what something should be called until you were good and ready. Ever since that time, I found that naming things is a big hindrance to evolving code from an experiment to a solution. Names get in the way until you're sure what the code is supposed to do (at which point, the above quote is true and you should be able to give it a descriptive name).
- jkire 11y agoI agree, though there is a difference between being able to explain something and naming it. I've been known to forget the word "door", but I could quite happily explain how it worked.
- ignoramous 11y agoMight be an outlier, IMO. 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.
- bshimmin 11y agoWhat 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).
- hyperpape 11y ago"Make the life of", I presume.
- DougWebb 11y agoHe 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.
- bshimmin 11y agoAh, thank you, you must be right. "Make life better for people..." would in each case have been grammatical and slightly more comprehensible to me!
- ignoramous 11y agoSorry, English isn't my first language, or second. Here's a link to the talk: https://youtu.be/bo36MrBfTk4?t=3446 https://youtu.be/bo36MrBfTk4?t=3446
- Retra 11y agoThere are things that operate like doors but are not actually doors. So when you are explaining how it works, you have ambiguity to resolve.
- douche 11y agoAs long as you have good refactoring tools (and aren't doing much stringly-typed reflection/XML based crap), renaming things as the design evolves isn't that difficult. Typically when I'm doing something new, it starts as a pretty free-form prototype, which gets progressively refined as I figure out what in the hell I'm actually doing, and start pulling components and subfunctions out of the original spaghetti ball.