1. Recontextualizing humanities skills for coding Elizabeth Wickes LIS Education Symposium, April 11, 2015

2. Coding. Let’s talk about this.

3. Between feelings and fire This isn’t a defense of why you should learn how to code. There are plenty of talks and articles covering that. This is how you should learn how to code.

4. Some honest talk Most of us aren’t from computer science or other STEM backgrounds. Most programming materials expect this preparation. We are a smaller audience, so this is just going to be reality for the foreseeable future.

5. But we have the skills! The act of going through an undergraduate education has specialized our learning skills. We self select into majors that speak to our interests and these programs shape our frameworks of the world. An awkward date: Me: In Sociology there is no real right answer. You come to a conclusion and justify it. Him: Don’t you feel freaked out by not knowing what the right answer should be? Me: Don’t you find that restricting?

6. We forget that we had to learn how to learn The higher we get in our home domains, the more that methodology seems to become a part of us and how we see the world. At the same time, the further we go the more we forget that we had to learn those things.

7. Until we move into foreign domains A lack of learning schemas creates undue difficulty for students entering into foreign domains. We aren't lacking the skills to succeed, we just need to recontextualize and remap our skills for new tasks.

8. So how do humanities skills fit into writing code?

9. Programs as research papers What are you writing? Short, to the point Single task Make this into that Long, lots of dependencies Making a nuanced point Handles lots of options, problems, etc.

10. Iteration Writing a paper Thesis statement Do some research Find supporting evidence Make your point Writing a program Define problem to solve Do some research Find supporting frameworks and tools Implement those Make your deliverable

11. Neither is written from start to finish We outline, develop, reevaluate, and trash Critical passes are always necessary Sometimes we need to kill it with fire and start again in the morning

12. Critical feedback is your friend Success through ‘failure’ Embrace revisions We learn to expect critical feedback on our writing and learn from it. Error messages are no different. They are not the universe casting judgment on your soul and finding you wanting.

13. Debugging as spell checking Debugging Look at your spelling Check your punctuation balance Check your containers and whitespace Make sure you said what you meant to say Spell checking Error is reported Locate the error Assess the construction of the word for errors Review the context of the word to confirm what it actually should be Make an appropriate correction

14. Be okay with not knowing how you’ll get there So you want to write a poem... Do you know how it will end when you start writing it? Should you?

15. Necessary uncertainty Simple battle plan 1.Receive input 2.Do magic 3.Profit Data project battle plan 1. Read in source file 2. Sort out magical need 3. Do magic 4. Produce glorious output Planning how you will do something is often impossible. Focus more on planning that you will do something rather than what you will do.

16. Reference materials You look up words in dictionaries, right? So use the documentation! Programming is not a reading/lecture/write a paper type of learning activity. Think of it as more of a reading/lecture/practice/refine/produce cycle.

17. General tips Focus on remembering concepts over syntax You can always look things up later Practice your words This will let you ask answerable questions Ask for feedback and be corrected gracefully Use the documentation Looking things up isn’t cheating Know the types of reference works Reference/Language/Topical/Cookbooks Find a cohort – you are not a lone wolf! Have something else to study when you need a break