Talks/accepted/day2/lessons-learned-presentation.md

#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