Q&A

Some comments on reflections and discussing and thinking about code more generally.

• raw_input vs input: my bad! But your text has the information you need to solve the confusion. Python 2 vs 3 & Trinket…
• Do the readings before the exercises. THanks to the reflections that helped me diagnose the confusion. The Assignments page order is now updated.
• Show me what you didn’t understand: If something’s not clicking for you, it’s OK to submit code that’s broken or isn’t working. Take the time to explain what’s not working, why, what you tried, etc. I can then revise your code to work in my feedback, which should make it click. Try to get things to work, of course, and many times trying to explain what’s wrong will help you figure things out. But if input isn’t making sense to you, for instance, still include it in your submission.
• Proportional feedback: Please spend lots of time on your comments and reflections. This isn’t to create work for you: it’s because it’s a huge part of the learning experience! Reading, Writing, Running, and Discussing code are the pillars of your learning and the key skills I want for you. In the beginning stages of class, I’m going to give everyone lots of feedback. As time goes on, the level of time I spend on feedback to you will become more and more proportional to the effort you put into your reflections.
• Length isn’t what’s important in a reflection: metacognition is! What have you learned about yourself and your understand? Your reflections and my feedback should be a dialog about that.
• Class and group discussions are another outlet for your metacognition. Listen to your classmates, ask them questions, and reflect on your own journey. As the semester goes on, you’ll get better and better at talking about code and reflecting on your efforts.
• Code is inherently social. But building your ability to interact productively with others about it, in writing and in person, you’re building an excellent foundation for your future efforts. This is crucial to lift off!

OK, let’s talk about some code then.

Assignments Review

Turtle Basics

What I Wanted to see:

• use lots of Turtle’s capabilities
• Using someone else’s code? Cite & Modify
• have a precise outcome
• relevant comments
• Reflection

Improvements:

• Explore!
• Put in the time
• Don’t copy code. Cite & modify

Examples…

Custom Turtles

• take user input
• make an awesome animation
• lightbulbs (e.g. calling variables vs strings)

Improvements:

• the Minimum Viable Submission (don’t do it)
• Beyond color (beyond the example)

Examples…

Chapter 2 Exercises

Quick Review & Q&A

Problem Solving Attitudes

• Self-awareness
• Calm
• Determination

Always know how you feel. This is critical. If you know you’re frustrated, that could be a key indicator that it’s time to go take a shower (or get a cup of tea, or do some yoga or…).

Keep in mind that you will understand the problem. Work backwards from that certainty.

Don’t let uncertainty overwhelm you or lessen your determination. Focus on the certainty you do have.

Talk it out.

If you’re crushing it , think about other ways the problem could be solved. If you’re not breaking a sweat - if you’re not initially confused about something - you’re not getting stronger.

Problem Solving Strategies

Go in the Right Direction

• Make sure you know what problem you’re trying to solve. Articulate it clearly. This is harder than it sounds.
• Make sure you know what you think you know. Test what you think you know to confirm it. Build from there.
• Keep your goals in mind. Sometimes you’ll discover you’re off on a tangent. Re-focus.

Work smart

• Start early.
• Make lists of what you need to accomplish. I use Google Keep. Separate the planning from the doing to keep your mind clear.
• Break the problem down into solvable pieces. At least one solveable piece will keep you moving forward. Once you’ve solved a piece, save/commit your work and take a breather.
• Time box. Work no more than 15-25 minutes at a time on a single problem.
• Stumped? Stop and come back later. In the shower is where many a tough programming problem has been solved.

Use Your Resources

• Who would know the answer? Find them, in person or via Google.
• Re-read the relevant parts in our textbook or the other resources I linked to in our syllabus.
• Know what to google for. Much of the help on the internet (e.g. StackOverflow) is too specific for the basics. Use a trusted reference when you can, be that a person or a book.

Problem Solving Tactics For Python

• print what you think things should be and see if they are
• see if you can predict what kind of Errors you’ll generate
• try and except errors you don’t care about for now
• Comment out (Ctrl-/ on Trinket) as much code as you can to isolate the problem

On Reflections

Here’s an outstanding reflection. Jasmine really gave me a sense of her journey. But more importantly, she went on that journey. As a graduate level class, I’m puting the onus on you to drive your own learning.

Editing a post from an open PR (I’ll be Tommy)

• Caroline: make another PR right quick

Let’s walk through adding or fixing something to an open PR. I’ve left a comment on everyone’s PR letting you know what’s missing.

• if your date format was wrong, fix that
• If you didn’t put your post in _posts/ghname/..., do that
• If I said “Great job” or something similar, make any edit you want to the body of your text.

TurtleHacks first post

Using the instructions from last time, and this, create a post for your Turtlehack and embed your Turtlehack trinket in there. Instructions for getting the embed code are here. Once your post header is made, paste your embed code in.

If you have your reflection ready, add that as well. If not, add it before midnight tonight.

This is due by midnight.

Github Review & Opening Issues

To maintain the quality of our site, we’re going to help police each others’ work. We’ll use Github Issues to do this, just like open source projects do.

Find a partner. On the people page the partner should have:

• First Post
  • Should have a well-formatted title
  • Should display the author’s github name
  • Should be formatted like a post
• Turtlehacks Post
  • Should have a well-formatted title
  • Should display the author’s github name
  • Should be formatted like a post

Go to our class repo’s Pull Requests tab. Filter by your partner’s name. Their Exercises Pull request:

• Should have a well-formatted pull request title
• Should have well-formatted YAML header with the correct author (their github name) and layout: post
• Should include three trinkets
• Should be in a file that’s in their subfolder, titled correctly.

Note: If you can’t find their post on the people page, there’s likely something wrong with their author: metadata field. Look on the main posts page for the post.

If any of these things are missing, Open an Issue, no more than one issue per assignment. Title it intelligibly, something like “@classmate’s Turtle post title needs spaces”. If there are multiple issues, you can be broader, like “Formatting issues with @classmate’s Turtle post”. In the issue, list the things that are missing. You can make checkboxes if needed like this:

- [ ] A checkbox item

Be helpful and let your partner know some details of how to fix the error. Here’s one I did in a previous class session that a student fixed.

@mention your partner on the issue. Once you all have commit access we’ll assign issues.

Handling Issues Assigned to You

If your partner found an issue, no worries! You have all the tools you need to fix it. Using the class notes, how-to sections and/or assignments, fix the issue via a pull request. In your pull request title or description, include the phrase “Fixes XX”, where XX is the number of the issue. This will create a link between your PR and the issue AND when the PR gets merged it will automatically close the issue. Neat!

In the beginning, issues won’t count against you. We’re still gettting the hang of things. If you have open issues from me or a classmate, learn why they happened and next time make sure to doublecheck those specific things. A large part of being successful in programming is paying attention to details, which often just means slowing down and/or using internal checkists for yourself.

But as the semester goes on, just like in a professional setting, creating extra work for your peers by doing low quality work will start to negatively impact my assessement of your work. So think of these first issues as FYIs of the things you’re still learning. Soon you’ll be expected to get all of this right every time so that we can focus on the content of your posts.

Github Questions

What’s a commit?

• A set of line-by-line changes to one or more files in a git repository

What’s a branch?

• A version of your source code. More precisely, it’s a sequnce of *commits that leads to the branch’s current state.

What’s the gh-pages branch?

• Where Github looks to automatically build a site

What’s a Pull Request?

• A social wrapper around the comparison between two branches designed to prepare for merging changes

What’s a Merge?

• A process of incorporating the commits from one branch into another. Usually done from a Pull Request but also doable from the command line.

What’s a merge conflict?

• When two or more commits specify changes to a single line of a file. These changes can’t be automatically integrated without potentially using work, so humans need to specify what should happen.

Fix Issues (~10 minutes)

A little in-class time to fix any outstanding issues.