"...winning happens before the game starts..." ☛ Scott Adams #quote

My recommendation is to introduce eight-ball into school curricula, but in a specific way. Each kid would be required to keep a log of hours spent practicing on his own time, and there would be no minimum requirement. Some kids could practice zero hours if they had no interest or access to a pool table. At the end of the school year, the entire class would compete in a tournament, and they would compare their results with how many hours they spent practicing. I think that would make real the connection between practice and results, in a way that regular schoolwork and sports do not. That would teach them that winning happens before the game starts

 

Boyd’s Law of Iteration: In implementing complex systems, it is better to act quickly than perfectly.

Boyd decided that the primary determinant to winning dogfights was not observing, orienting, planning, or acting better. The primary determinant to winning dogfights was observing, orienting, planning, and acting faster. In other words, how quickly one could iterate. Speed of iteration, Boyd suggested, beats quality of iteration.

The next question Boyd asked is this: why would the F-86 iterate faster? The reason, he concluded, was something that nobody had thought was particularly important. It was the fact that the F-86 had a hydraulic flight stick whereas the MiG-15 had a manual flight stick. 

Without hydraulics, it took slightly more physical energy to move the MiG-15 flight stick than it did the F-86 flight stick. Even though the MiG-15 would turn faster (or climb higher) once the stick was moved, the amount of energy it took to move the stick was slightly greater for the MiG-15 pilot. 

With each iteration, the MiG-15 pilot grew a little more fatigued than the F-86 pilot. And as he gets more fatigued, it took just a little bit longer to complete his OOPA loop. The MiG-15 pilot didn’t lose because he got outfought. He lost because he got out-OOPAed. 

I’ll state Boyd’s discovery as Boyd’s Law of Iteration: In implementing complex systems, it is better to act quickly than perfectly.

From Simple Architectures for Complex Enterprises (PRO-best Practices) (Best Practices (Microsoft))

I stumbled across this book in the local Barnes and Noble and opened it to a random page. This story. Interesting...

"How to recognize a good programmer" ☛ http://inter-sections.net

Positive indicators:

  • Passionate about technology
  • Programs as a hobby
  • Will talk your ear off on a technical subject if encouraged
  • Significant (and often numerous) personal side-projects over the years
  • Learns new technologies on his/her own
  • Opinionated about which technologies are better for various usages
  • Very uncomfortable about the idea of working with a technology he doesn’t believe to be “right”
  • Clearly smart, can have great conversations on a variety of topics
  • Started programming long before university/work
  • Has some hidden “icebergs”, large personal projects under the CV radar
  • Knowledge of a large variety of unrelated technologies (may not be on CV)

Negative indicators:

  • Programming is a day job
  • Don’t really want to “talk shop”, even when encouraged to
  • Learns new technologies in company-sponsored courses
  • Happy to work with whatever technology you’ve picked, “all technologies are good”
  • Doesn’t seem too smart
  • Started programming at university
  • All programming experience is on the CV
  • Focused mainly on one or two technology stacks (e.g. everything to do with developing a java application), with no experience outside of it