notes from my talk

accepted/day2/lessons-learned-presentation.md

@@ -0,0 +1,164 @@
+#Get better at helping people with programming
+
+Marina Kukso
+
+@marinakukso
+
+---
+
+#things i didn't know when i was a beginner
+
+* the big boy voice is bullshit
+* i am not dumb if i don't understand what you're telling me
+* it's not strange if i don't know x - i just don't know it.
+* "the DOM"
+* relationship b/w hardware and software
+* how to use sample code & install instructions
+* prog is a skill that you can learn like other skills.
+* why programming books start with data types
+* there are crystals inside computers
+* what exactly a bit is
+
+---
+
+#experiences i had already had when i was a beginner
+
+* geocities, html
+* CS1 in college (java, eclipse)
+* fetishization of programming
+* "what it's like to be a woman at a bitcoin meetup"
+* bad outcomes when i asked questions
+
+---
+
+#things that didn't work for me
+
+* "ok, type console.log"
+* "install firebug. you'll need it."
+* online code schools & other non-interoperable things
+* "just learn python"
+* intro to github
+* skeleton css framework
+
+---
+
+#things that worked for me - laying the groundwork
+
+* html, geocities
+* taking a computer apart
+* bits & how computers store info
+* pen and paper registry, data structures, pseudocode
+* computer/programming "ask me anything" sessions
+* being around nice hackerpeople
+
+---
+
+#things that worked for me - programming
+
+* figured out that i needed to learn linux before a prog language
+* bash - sit with tutee & do things via command line
+* analogies and examples
+* writing programs from scratch
+* working with node (most people will be happy to make a website)
+* concrete projects: neocities, studio.substack.net, voxel.js, hardware, scripts
+* amazing mentors, ongoing mentorship
+* mentors pushed me to ask questions until i understood
+* computerphile - "how would you make a computer do x"
+
+---
+
+#general tips
+
+* empathy!
+* assume as little as possible about the learner - ask q's
+* constant feedback loop between you and the learner
+* reassurance (personal stories) can be helpful
+* examples, analogies, demonstrate on your comp
+* history of computing - give the context! (eg origin of text-based interfaces.)
+* help them set up an environment that will allow them to keep learning on their own
+* person who sees self as beginner may not feel empowered to ask q's
+* silence is not "i understand." check in at every step.
+* ask q's until you understand what they're confused about
+* read between the lines. xy problem. beginners often don't
+   use the right words to describe a problem.
+* be aware of power you may hold in a situation
+* you don't have to help all the time. "i'm busy right now", man pages
+* jargon: focus on relevance/function; explain any jargon
+   in your explanation; if you are giving a very accurate, specific
+   explanation, explain why these seemingly minor
+   distinctions matter.
+
+---
+
+#specific tips
+
+* don't touch learner's keyboard
+* no, please: "it's easy"/"just do..."
+* "are you familiar with?"
+* "does that make sense?" 
+* "are you stuck on anything?"
+* "do you know what to do next?"
+* man pages, googling, reading errors
+* don't say "guy" for "person"
+* be aware of how you present to others - big boy voice, don't stare!
+* as a mentor, you are responsible for the tenor of the
+   learning environment - ya gotta enforce!
+* "do you have any ideas for what to work on?" if not, share
+   ideas that would be within reach of that person
+* many want to learn prog for "practical" reasons, but not all!
+* if a noob seems to be using a bad/weird tool, ask about it
+   & chat. (don't be dismissive or just suggest another tool
+   w/no explanation. give context.)
+
+---
+
+#secrets you should tell learners
+
+* programmers use linux
+* "which distro?" - k/l/ubuntu is well-supported
+* "which language?" = "i'm not sure what to learn first".
+   start with bash!
+* how programmers use IRC
+* don't get taken in by those who use the big boy voice
+* you don't have to take hazing/trolling/dickishness
+* much of programming is not writing difficult algorithms
+* much of programming is not hot shit. boring, useless, not wizardry.
+* you don't have to memorize all the commands in the book
+* linux commands are programs
+* what built-in methods are
+* don't update linux
+* shell tips: .. , tab complete, history 
+* dev environment: text editors, git & github
+* how "professional websites" get built: dev vs production, bug trackers, etc.
+* what is localhost and how to run a dev version of your thing
+* everyone googles all the time
+* pros don't just have all errors & solutions memorized.
+   they've just learned through suffering through many errors.
+   one day this will be you! :D
+* no: "i'm stuck on x but it's supposed to be easy!" it's
+   frustrating, but the more time you spend, the faster
+   you'll get. you will learn through pain :P
+* there are common patterns in programming.
+* if you don't get it, it doesn't make you dumb.
+* you don't always have to know every detail of a thing to use it
+* server program vs server computer
+* different ways that the word "API" is used
+* package manager as "free app store"
+* solving problems w/a bag of command line apps vs giant gui program
+* common command line apps - mplayer, imagemagick, youtube-dl, etc.
+* large software & bags of utilities (frameworks, d3, etc.) vs small libraries
+* types of work that's out there (front end, back end, sys admins)
+* existing controversies & hierarchies in the field
+* command line seems hard, but is easy. programming seems easy, but is hard.
+
+---
+
+#running a collaborative learning group
+
+* space
+* mentors
+* learners
+* calendar
+* noise
+* surprise treats are great
+* encourage co-learning