Comment by WillAdams
1 day ago
Some notable stories from Folklore.org:
https://www.folklore.org/Joining_Apple_Computer.html
https://www.folklore.org/Negative_2000_Lines_Of_Code.html --- something to bring up whenever lines of code as a metric is put forward
https://www.folklore.org/Rosings_Rascals.html --- story of how the Macintosh Finder came to be
https://www.folklore.org/I_Still_Remember_Regions.html --- surviving a car accident
“Busy Being Born” https://www.folklore.org/Busy_Being_Born.html , with its priceless early glimpses of the Lisa/Mac UI preserved in Polaroid photos, may be the best.
This shows amazing foresight on Bill's part. It would have been easy for all that to be lost.
Here is a video of Bill showing and discussing those Polaroids: https://m.youtube.com/watch?v=Qg0mHFcB510
The lines of code story is a timeless classic.
> He thought and wrote "-2000 lines". Management stopped asking Bill to fill out the form.
This lesson stuck with me for years. Final results alone are measurable, not productivity.
Imagine being the manager that had to assess Bill Atkinson's productivity!
> Final results alone are measurable
Not even those, for individuals
Mostly we work in teams. I myself like to work in "plumbing" that is arbitrarily far from "final results"
Score code on line count and runtime golf. Shorter, faster, and fastest time to completion is best.
Code that’s 4K and took slightly less time to write but runs slightly faster than code that’s 400 bytes that took another 30m to write still doesn’t get the best score.
I kind think metrics are not the answer and instead one needs taste. Obviously performance is multidimensional both in what one measures (latency vs throughput) and as a function of the input. The solution you imagine that is slightly faster in the test could avoid (or introduce) different worst-case or asymptotic behaviour, for example.
1 reply →
> Shorter, faster, and fastest time to completion is best.
What about correctness, robustness, readability, clarity, maintainability?