#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