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