1
0
Fork 0
You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Talks/accepted/day2/lessons-learned-presentatio...

5.5 KiB

#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