diff --git a/accepted/day2/lessons-learned-presentation.md b/accepted/day2/lessons-learned-presentation.md new file mode 100644 index 0000000..71db9bd --- /dev/null +++ b/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