Hacker News new | past | comments | ask | show | jobs | submit login

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).




I 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.


Might 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.


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.


Ah, thank you, you must be right. "Make life better for people..." would in each case have been grammatical and slightly more comprehensible to me!


"Make the life of", I presume.


Sorry, English isn't my first language, or second.

Here's a link to the talk: https://youtu.be/bo36MrBfTk4?t=3446


There are things that operate like doors but are not actually doors. So when you are explaining how it works, you have ambiguity to resolve.


As 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: