I'm watching the talk today called "Making Badass Developers", by Kathy Sierra with some coworkers at Glitch.

# Talk Notes

• Cognitive resources are finite.
  • Studies have shown that if you are asked to remember 7 numbers instead of 2, you will likely have a harder time being patient or making 'good' decisions in other settings (like picking fruit over cake when you're dieting).

Kathy describes a phenomenon called 'Pile up on B' - you have some stuff you want to learn in Pile A (Can't do it but need to), a lot of stuff in Pile B (can kinda do it, with effort), and a few things in Pile C (Mastered it, reliable & automatic). But there are so many things to do in B that you never get to work on Pile C. There are a couple ways to fix this.

• One is by breaking up the things in Pile B into subtasks, smaller goals that can be mastered in no more than 3 sessions of 45-90 minutes. Move more skills to Pile C (mastered it) so that you can feel like you're making progress and spend fewer cognitive resources doing it.
• Another is that it's very slow to get to Pile C for a skill. (It takes a long time to master something).
  • Kathy suggests bypassing pile B when possible, and speeding up A to B to C when possible.
    • Some people get really good at skills without really understanding what rules they are following within that skill. Examples include chicken sexing (telling the sex of a baby chick by looking at it, which is apparently quite hard), and spotting planes during WWII and determining if they are friendly or enemy planes. The secret here is to learn from someone who knows the right answer, guess and have them correct you, and eventually your brain will get better at the identification task. This is called perceptual learning. Perceptual learning was underrated for a long time because researchers didn't realize that the brain was doing serious pattern-matching work without telling the person doing it that it was happening. Brains are great at pattern-matching!
    • The way to take advantage of perceptual learning on your own is to look at a very high quantity (200-300) of * high quality examples. This is hard to do on your own, because it's hard to find a big library of great examples to learn from.

Practice doesn't make perfect, practice makes permanent. The longer you do beginner activities as practice, the longer you will be a beginner.

# Discussion Notes

• Tim feels he has gotten faster at learning over time. Perhaps this is because he's gotten better at not asking questions about things he doesn't need to know yet? TDD (test driven development) also seems to help. You just have to focus on getting the test to pass, and worry about the next little edge case for everyone. You have to write a test case that fails before moving on to touching the code again.

• Johnicholas shares one developer's attempt to create a library of examples like Kathy Sierra suggests.

• Angelo: There are a lot of peripheral questions that reduce developer productivity. "Have I updated these 3 tools with what I'm doing?", "What's going on with my benefits?", etc. Our receipt validation system for expenses is acknowledged by the room as a productivity killer - now I must stop what I'm doing and go find receipts.

• The number of examples that it takes to learn something that Kathy mentioned is fascinating to Rachel. Could Glitch be a source of good examples?

• Cassey (me!) talks about learning to code with the wonderful book Think Python, which provides short exercises after every section that introduces a new concept. "You just learned about for loops! Apropos of nothing, write a program that prints the numbers from 1-20." For me it was very helpful in helping connect a concept immediately to how it would be used, which made it feel more real.

• I also mention the parallels to learning human languages (think Spanish, German, etc) which come quickly to me. I'm learning a language with the aid of Duolingo for this first time (French & Spanish came before those apps for me), and while it's fun, I find there aren't nearly enough repetitions for me to feel like I've mastered a set of words before Duolingo tells me I can move on. So, I end up repeating lessons on my own and running 'review' sessions over and over, which is maybe unnecessary but now I will never forget the German word for duck. (Die Ente!) I also tend to learn languages quickly because I'm not afraid of making mistakes and being corrected, so I guess at words (especially when learning Spanish as an English & French speaker - this must be un cognado with one of them, right?)[1] and wait for a correction, which perhaps works a bit through perceptual learning.

• Another member of the discussion group says that for languages, they really hate being wrong and being corrected, so they have progressed much more slowly in speaking than in reading & writing in multiple languages.

[1] - Sidenote - in typing up this post I did the exact thing I'm trying to describe - I typed uno cognato as a Spanification of 'cognate', and then realized in order to not confuse people I should find the accurate translation and use that. I got pretty close with guessing!