* You get a multiplier from using the right tools
* You get a multiplier from using tools you know well
* You get a multiplier from having solved a similar problem before
* You get a multiplier from understanding the requirement well enough that you:
- Don't risk solving the wrong problem by
working from a spec that someone else has written
- Don't have to ask lots of questions of your customer
(and wait on the answers)In the marketing we're trying to walk a narrow line between encouraging people to look at existing code and learn from it, without encouraging plagiarism. (http://etia.co.uk/pop/about/)
Say I want to calculate the interval in seconds between two timestamps, and I'm getting an error on my line of python code:
start_time = datetime.now()
If I search for uses of datetime in some open source code
and find this: start_time = datetime.datetime.now()
I might learn that the now method is in a subpackage of datetime, itself called datetime. This fixes my problem, and I think that's ok because I've learned where the now() function is in the package namespace, rather than copied anything.On the other hand if I see code like this
(datetime.datetime.now()-start_time).total_seconds()
I've learned that I can subtract results of datetime's now method and that whatever kind of object I get back has a total_seconds method. But I'm a bit less comfortable. Any code I write is reusing the algorithm even if my code ends up with different variable names and splits this logic over additional lines. On the other hand algorithms aren't patentable, so maybe it's ok to use the algorithm.We don't seem to talk much about this. I'm convinced we can learn a lot from looking at other peoples' code; architects don't avoid looking at other architects buildings, and authors don't avoid reading other authors books. It's surely a good way to learn best practice.
Do HN'ers look at other people's code? Where do you draw the line?