Should you start with code?

print "hello world"

There, now we've started with code.

Now, let's back up.

Some of you won't need this lecture

But you're still going to sit through it.

Social stats class...

• First week was only "Let's not be afraid of math."
• I raged.
• Then I started teaching programming, and I understood.

Learning

• We're born with the desire to learn
• But not the skill of learning
• Students with learning disabilities get this
  • We have to learn how to learn in a normative way.
  • Creates an awareness of the act of learning.

Learning specializations

• Post-secondary education teaches us how to learn in our home domains.
  • Intro classes give us the foundations.

An awkward date

Me:  There is no right answer for a lot of what we do.  You have to make an answer of your own and explain it.

Him:  Don’t you feel freaked out by not knowing what the answer should be?

Me:  Don’t you feel restricted by there only being one answer?

 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.

And we forget that we had to learn it.

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.

Recontextualizing humanities skills to programming

1) Iteration

Programs as research papers

• Short, to the point
  • Single task
  • Make this into that
• Long, lots of dependencies
  • Making a nuanced point
  • Handles lots of options,
    problems, etc.

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

No paper or program is written from start to finish

• We outline, develop, reevaluate, and trash
• No program or paper is written perfectly from left to right
• Critical passes are always necessary
• Sometimes we need to kill it with fire and start again in the morning

2) 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.

Debugging as spell checking

• Error is reported by our text editor
• 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

Suggested steps for debugging:

• Look at your spelling
• Check your punctuation balance
• Check your containers and whitespace
• Make sure you said what you meant to say

3) Break a task into small goals

Be okay with not knowing how you'll get there

So you want to write a poem...

• Do you know how it will end before you start writing it?

Should you know?

Simple battle plan

1. Receive input
2. Do magic
3. Profit

Data project battle plan

1. Read in source file
2. Sort out magical needs
3. Do magic
4. Produce glorious output

Necessary uncertainty

Planning how you will do something is often impossible.  

Focus more on planning that you will do something rather than what you will do.

You know all this stuff, programming just uses it in a different way.

Now, for some tips...

Tips for this new universe

1) Focus on concepts over syntax

This is a different kind of lecture.

You can always look up something later...

but you need to remember that it exists.

What to take notes on?

• Determine what the speaker is explaining:
  • A concept? feature? function? tip or trick?
• Take notes at the level of the instructor's granularity
  • Concepts: don't worry about the code
  • Features: note the name of the feature
  • Functions: note the name of the function
• Demos are different
  • Try to type everything along with the instructor
    • But don't feel bad if you get lost, just listen

2) Learning names is important

Practice using your words

Use the proper names for the things you are seeing

• This takes lots of practice
• Understand that there are technical synonyms and synonyms of practice
• Ask for feedback, and be corrected gracefully

3) Documentation is your friend

Looking things up isn't cheating

You look up words in dictionaries, right?

• Again, focus on remembering that there are functions and tools for things, not memorizing how they work
• Documentation is there to help clarify syntax and show you everything that can be done with a toolset.
  • Instruction is there to show you the toolsets exist.
• Bookmark the docs or things that help you.  
  • Seriously.

• Reference materials
  • Official docs, web pages, etc.
  • Look up what functions are available to you, the syntax rules, and examples.
• ​Language guides
  • ​"Introduction to..." books
  • Usually have a domain angle, e.g. games, computation, text, etc.

• Topical books
  • Focuses on one topic, intro to topic, not language
  • General topic, one utility package, etc.
• ​Cookbooks
  • ​Mostly general use, sometimes topical
  • Problem/Solution/Discussion framework

Types of reference works

4) Programming is a social activity

You are not a lone wolf

You have cohorts

• Classmates
• Instructors
• Community of practice
• Language community

Many cohorts are vocal

• Lots of resources online
• Lots of people who want to help
• Make use of them!

Embrace specialization

• Be okay with not knowing everything
• Society began occupational specialization for a reason
• Specialization requires collaboration
  • seek help
  • listen to conversations
  • ask questions

5) Have something else to study

At some point you'll be sick of it and need a break

This is fine.

This is normal.

Other things to study

This will depend on why you are learning how to program.

I guarantee there will be other tools and structures you'll need to learn.

Make a list for when you need a break.

Text processing stack:

• regular expressions
• HTML
• XML
• XPath
• XSLT
• and the list goes on...

"But I've heard that programming is hard?"

And research papers aren't?

Keep calm

and

read your

error messages

Or, how I learned to stop worrying and finish debugging my code.

You will get errors.

Errors are not failures.

Sometimes we get this...

How to deal

• Calm the perfectionist portion of your lizard brain
• Errors are there to be helpful
  • Sometimes they aren't, but that's another lecture.
     
• Read them
• Put your detective hats on
• As a co-worker once told me:
  "Developers should be constantly breaking things."
• Invention through experimentation

Your eyes won't know where to look in code

• The more you look at code, the better developed your visual parser will be.
• Ever taken an art class?  Think of how you looked at a painting before and after.

Having all the feelings is normal

How to deal

Try rubber duck debugging.

There is no end moment when you are done learning

(such under development. so in progress.)

Ready?