gorhgorh 5 years ago
3 changed files with 182 additions and 14 deletions
  1. +18
  2. +164
  3. +0

+ 18
- 0
accepted/day2/call-to-action.md View File

@ -0,0 +1,18 @@
Speaker: hoegrammer
Tags: refugees, digital exclusion
This talk is a call to action, and a cry for help.
Digital exclusion is a huge problem for refugees. Without passports, they can't buy mobile data. Money is also a problem for many. Wifi cafes only go so far.
The psychological necessity of communicating with family and friends is only part of it. Rumours, misinformation and lies spread like wildfire. People are not getting the information they need to make decisions about their future. They don't know what is legal and what is not. And now, unbelievably, the Greek government has decided to offer asylum registration ONLY THROUGH SKYPE, FOR FUCK'S SAKE.
I'll talk about how I failed them at Ritsona camp in recent weeks, and how I hope to do better. About the problems we face, politically and technologically.
I have only basic knowledge of networking technology, but now seems like a perfect time to learn. I'll be asking for advice on quick, simple ways to get people online, and wisdom about the politics involved as well.
Secure communication is also an issue - for volunteers working outside of the law, as well as the refugees themselves.
The ISPs, the mobile networks, the corporations will not deliver to these vulnerable people the connectivity which has become almost a human right.
If anyone's going to help them, it can only be people like us.

+ 164
- 0
accepted/day2/lessons-learned-presentation.md View File

@ -0,0 +1,164 @@
#Get better at helping people with programming
Marina Kukso
#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

+ 0
- 14
accepted/day2/stealth-refactoring.md View File

@ -1,14 +0,0 @@
# How Stealth Refactoring is Wrecking our Codebases
Speaker : naomi rosenberg
tag : refactoring, micro-management, professionalism
Because management are perceived not to value refactoring, developers fear being “told off” for doing it. So we refactor less than we’d like to, and when we do, we often sneak it in, hidden amongst functional changes.
We know insufficient refactoring leads to technical debt. Stealth refactoring creates problems, too. Reviewing a diff mixing functional and non-functional changes is time-consuming and error-prone, costing money and introducing bugs. Also, stealth refactoring tends to focus only on the “geographical area” - the function, file or module - that we are “touching” at the time. What are the implications of that for the coherence and consistency of our codebases?
I will make some technical suggestions for optimising how we refactor, but the main issue is cultural. Is our shame around refactoring entirely due to management, or are devs responsible too? How can we sell simplicity to people who may not be aware of its value? Can we create a culture that legitimises - or even rewards! - a practice that is, after all, essential to developing good software?
need travel fee : N
need room : Y
Location : Planet Earth