If I could just recommend this book right now: http://pragprog.com/titles/ahptl/pragmatic-thinking-and-learning Amongst other thinks, it refers quite extensively to the Dreyfus Model: http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition
In particular, there's a section where it discusses the formalisation of rules, and I'm reminded of one case study in particular. - A group of pilots was identified, and the experts in the group were tasked to write a detailed set of instructions / decision tree on how to perform some particular task. - The novices then got to perform this task, either without the guide or following it exactly. Following it helped their performance. - The experts then did the same, they had to draw on experience or follow it exactly. The guide turned out to do more harm than good. When analysed, it was shown that the experts were making decisions based on contextual information, or the synthesis of lots of data. The basis of these decisions was not something that could practically be condensed into the guidelines, and this acted as a straightjacket - actively preventing them from drawing on their expertise. <http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition>I wish I could remember exactly what the task was, and the performance analysis criteria, but it was definitely something large with plenty of steps :) So... given the reported performance differential between "good" and "bad" programmers, is there a net benefit in such a guide if it holds back the best performers? On 21 September 2010 03:02, Josh Berry <tae...@gmail.com> wrote: > On Mon, Sep 20, 2010 at 2:49 PM, Reinier Zwitserloot > <reini...@gmail.com>wrote: > >> Indeed, it is very related. In that it's stupid. There's great value >> in debating which style is best, but once the pros and cons are >> weighed, there's far more benefit in everyone standardizing on the >> same thing than everyone going off and doing their own thing. That's >> all *IF* there is no real benefit in having multiple styles. I'll >> gladly go on record to say that there is absolutely no point >> whatsoever in having both tab-indent and space-indent around as >> styles. >> >> > It sounds like we are almost in violent agreement. The main difference is > that I don't even cede that there is an advantage to abolishing tabs or > spaces. In my editors of choice, both can live quite happily. In fact, it > is only annoying when I see someone's editor made to flag the one they don't > like with a hideous marking. (I will gladly say that I have grown > distrustful of any language where there is a semantic difference between > tabs and spaces.) > > So, I think I agree with your reasoning. I just haven't seen a "codified > style" that actually does away with mistakes. :) Are there any examples? > I offered "literate programming" as a practice within languages that > produces elegant results. Sadly, I don't know as that that can be codified. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to javapo...@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- Kevin Wright mail / gtalk / msn : kev.lee.wri...@gmail.com pulse / skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
