mcshaner1

For anyone reading stuff like this, read Ellul’s Technological Society instead. Optionally followed by “The Meaning of the City.” I haven’t read the manifesto and don’t plan to; it apparently cited Ellul a fair amount and Ellul seems like a saner guide.

FYI - There’s a nice set of lectures by Aubrey Clayton on this book if you want to supplement your reading.

https://youtube.com/playlist?list=PL9v9IXDsJkktefQzX39wC2YG0...

That interconnect was 3 or 4 orders of magnitude faster than Ethernet at the time for things like barrier synchronization and the hardware was fairly simple. [1]

http://aggregate.org/AFN/ has more, including hardware designs.

[1] http://aggregate.org/TechPub/spdp96a.pdf

Are you thinking of HP’s Dynamo? http://cseweb.ucsd.edu/classes/sp00/cse231/dynamopldi.pdf

That makes sense, a couple of years ago there was a lot of misleading interpretations going around, precise definitions help clear things up. I read Peak a while back, and I must’ve forgot that distinction.

I found the Klein book you mentioned more useful than Ericsson’s as well, that Fadde/Klein paper I mentioned was also pretty helpful. I need to reread both, and put them into practice more than I have. I read too much, and I don’t get the tacit knowledge that comes from experience...

Another good book is Surpassing Ourselves by Bereiter and Scardamalia. They studied how students developed writing skill. Their definition of expertise is a bit different than Ericsson’s, but I think it is more useful.

I think there is room for nuance here. True deliberate practice is easiest to apply in those domains, but there are some lessons from Ericsson's work that can be applied using the NDM framework. I think the point that people miss often is that it is deliberate practice, not just practice. While we may not be able to practice like a potential chess grand master, we can deliberately challenge ourselves and look to learn from our mistakes. If you squint hard enough, some of what Klein writes about in "The Power of Intuition" seem like attempts to deliberately practice something in a field without that long tradition of pedagogical development (or fields that don't train for tacit knowledge). His paper with Peter Fadde, "Deliberate Performance" also talks about this. That said, you sometimes don't learn the right lessons, and if the situation changes too dramatically, all your tacit knowledge might work against you.

One tangent comment to go with this: One of Klein's occasional coauthors, Robert Hoffman, co-wrote a book on expert weather forecasters that I really liked. Weather is hard to predict, but one thing they found that what the best forecasters did was to look at the data before looking at what the computer models predicted. Once they had an idea of what they thought the weather might look like, they compared with the model. This kept their skills sharp and ensured that they continued to learn.

I’m not quite sure these would be what you’re looking for, but I enjoyed the following:

Seeing Like a Rover - Janet Vertesi

Human-Machine Reconfigurations - Lucy Suchman

Where the Action Is - Paul Dourish

Seeing Like a State - James C. Scott

There are a couple shorter videos with Hackaday, Mill CPU for Humans.

Do you have a recommended starting point?

I think the optimal base is actually the natural log e, or about 2.71. I saw a derivation of this before but can't find the reference. Ternary actually comes about a bit better from an information density standpoint, but all the other points you made about difficulties with base 3 and benefits of base 2 still stand.

I'm sure this isn't what Graeham had in mind with this post, but I'll comment anyway: Steven Spear identifies rapid experimentation as one of Toyota's strengths, not necessarily in product development, but developing how they build the product. An example given in his book was checking to see if adjusting the height of a source of parts. Rather than welding it a new position, bolting it, or even using duct tape, the fastest way to check is to just hold it there. It's cheaper and faster. When you lower the costs (both money and time) of experimentation, learning happens more quickly. Or as this post puts it: "the more you can build quickly, the faster you can find what you don’t know"

Rapid prototyping/experimentation leads to rapid feedback, which in turn can lead to rapid learning.

Something bothers me about Bret's writings: He is very big picture (which isn't bad by any means), but then he often talks in absolutes without substantiating many of his claims. I suppose speaking in absolutes may be for rhetorical reasons, something wishy washy is probably less persuasive. He certainly has some good ideas and a talent for presenting them though.

>Programming is a way of thinking

If teaching programming is meant to teach a way of thinking, how do we ensure that it transfers to other areas? David Perkins discusses this in his book "Outsmarting IQ" (pg 224, http://books.google.com/books?id=kNbSvy4dQEUC&q=papert#v...). Latin was once thought to be a language that taught people how to think, but the studies didn't show any transfer between learning Latin and other skills. Obviously, programming isn't Latin, and I'm actually in support of the idea of teaching programming as a way to teach thinking skills, but any effort to do is going to have to address the problem of transfer. One way to potentially do this is motivation, I think Vygotsky advocated showing children why they could write (and how they might already be attempting to do so), which would then give them motivation to learn writing. They'd already understand a reason for using it...

> Alan Perlis wrote, "To understand a program, you must become both the machine and the program." This view is a mistake, and it is this widespread and virulent mistake that keeps programming a difficult and obscure art. A person is not a machine, and should not be forced to think like one.

There are cases where this is true, but putting it another way, "A teacher is not a student, and shouldn't be forced to think like one". Any time where a mind is trying to communicate some concept, there has to be some level of dialogue or shared context. One could argue that learning programming could help people understand that others may interpret what they say in a different way (and why that may occur). I think that is a pretty important concept.

Finally, the US military has funded a lot of research on intelligent tutoring systems. One of the things a lot of the successful programs have is a means of getting the user to think more like an expert. The tutor programs often do this in two ways: by prompting the trainee for a response and then getting them to compare to something an expert would do, and by providing feedback/hints (at the right level) as needed. Vygotsky discussed the latter in "Mind in Society", sometimes all a person needs is a little assistance at the right time, and then they'll understand why and how to do something. As far as computer based training systems, "Development of Professional Expertise" has some interesting papers, though it may not be the best source.

I've been investigating this question recently as well. I am not a great programmer, so take this with a grain of salt. Also, I might ramble a bit, but I'm still trying to figure this out myself.

I think the biggest thing is to work on continuously improving/rewriting/refactoring code. You might even start by studying solid code from someone else and try to rewrite it from memory until you can match or improve the original. After each iteration of rewriting from memory, compare to the original and see how it measures up. What did they do differently and why? Obviously, this has to be code of a manageable size for your current ability. Ben Franklin did this with writing he admired, and Steve Wozniak did it with circuit layout.

Beyond this, I found a couple of papers/articles that might be useful.

http://web.coehs.siu.edu/units/ci/faculty/pfadde/Research/De... The first is about deliberate performance, which is a combination of deliberate practice with your typical work requirements. Try to make predictions about how things will work or how long they will take to complete and write it down. Check the accuracy of your predictions. What threw you off? How could you do better? If there were different constraints, what would that change? I've found writing down my thought process to be useful in problem solving. What do I know? What am I trying to do and how might I do it? What are the implications of that choice? Test driven development could be a useful tool in this process as well.

If there is someone who is more skilled, try to imagine what they might do. If things don't work as you expected, explain your thinking to them and ask what went wrong. Have people evaluate your code. One of the reasons really good programmers crop up in open source is that they have quick feedback on code quality, so contribute to a project like that.

http://www.newyorker.com/reporting/2011/10/03/111003fa_fact_... This second article is by Atul Gawande, it describes how coaching can be applied to medicine. If you can find someone to fill this role for you, ask them.

Finally look at these links from Quora/Stack Overflow... http://www.quora.com/How-does-one-systematically-go-about-be... http://www.quora.com/What-are-some-tips-for-advanced-writers... http://stackoverflow.com/questions/3605461/how-does-a-progra...

Regarding his books, he explicitly states the valedictorian approach is probably wrong for most students in one of his books (The High School Superstar one). He recommends almost the opposite approach, which seems to be close to what you are saying, do well enough to get your foot in the door grade wise and go deep in something interesting.

Little's Law is probably CS folks should know too. It is relatively simple, but useful

https://en.wikipedia.org/wiki/Little%27s_law

I think these are reasonably good, but I can't say I've read every paper on either list. They are reading lists for qualifying exams rather than a course, but I think they'll still be useful.

Wisconsin Arch: http://pages.cs.wisc.edu/~karu/qualwiki/

UIUC Arch: http://rsim.cs.illinois.edu/arch/arch_qual.html

One of the problems with new stories (for me at least) is when they are submitted. I often see something interesting in the rss feed that was submitted several hours before I got to it. Upvoting on a story that old is useless, if it hasn't reached critical mass by some time threshold, no one will see it.

It is a good filter for low quality content, but it also filters out things I find interesting.