Session 2 Problem Solving, Pseudocoding, Git


  • explain the purpose of git
  • initialize, add, and commit changes in a local repository
  • define and understand iteration at a high level
  • define psuedocoding and problem solving strategies
  • understand and practice Driver - Navigator pairing approach
  • write pseudocode and break problem into smaller steps


  • Housekeeping, Feedback + Goals
  • Git Basics
  • Iteration in Programming
  • Problem Solving + Pseudocode
  • Wrap Up


  • Notebook
  • Writing instrument
  • Laptop
  • Headphones & mic
  • Zoom permission to share screen for breakout sessions

Housekeeping, Feedback, and Goals

  • You will be screensharing your terminal today. If you have programs open that might be distracting (or you have confidential work open), close or minimize those programs now.


  • Ask questions or post struggles you have in the public Slack channel! This is a win-win-win for everybody.


  • For homework, we’ll be leaving feedback on your practice tasks and also checking, but not leaving feedback on your readings and responses.

Intros and Review

1. Introduce yourself: name, pronouns

2. What was your biggest takeaway from Session 1?

3. Work through the terminal commands review below using driver/navigator.

Terminal Commands Review

  1. Type cd to get to your home directory (you'll probably already be here, but do it just to be sure)
  2. Make a new directory called session2_review
  3. Move into the session2_review directory
  4. Print the path to your current directory
  5. Make a file called
  6. Make a file called
  7. Make a file called
  8. List the contents of your directory (you should see the three files you created)
  9. Add the text "Git is a version control system" to the file
  10. Remove the session2_review directory


Git is a Version Control System (VCS). It allows you to save work on your project, and reference previous states of a project if needed. Normally when we save something on our computer, the newer version overwrites the older version. This is problematic if we need to look back at an earlier version. Git solves this problem by providing you multiple save points. You can get the current version, and ANY previous version. Git’s philosophy: never lose anything.

Git works similarly to the way that Google Docs tracks changes across time. Let’s take a brief detour to this Google doc.

Why Use Git?

There are numerous reasons to use git. Among them:

  • The ability to “go back in time” to previous versions of your code if you break something
  • The ability to “go back in time” to previous versions of your code if you change your mind about a feature
  • The ability to chunk parts of your work so that you can choose from chunks to keep at a later time
  • The ability to work collaboratively on the same project (even the same files!)
  • The ability to use branches to separate features of a program
  • The ability to track who made specific changes to specific files

In this section on git, we’ll learn (or review) these git comamnds:

Action Commands

Safe/Informative Commands

Things to Note

Git has a steep learning curve, and it can be super confusing at the beginning. Tonight's lesson is not meant to make you a git expert, but it will expose you to the basic git commands and workflow. Most likely, you will not have the commands or workflow memorized after tonight.

To get comfortable with git (just like with anything else), you will need to put in hours of practice. It's an excellent idea to go back over this lesson (either in print or recording) multiple times.

Watch and take notes during the demonstration of the git workflow. After the demonstration, we’ll move into breakout rooms where you’ll get to try with your group.

Getting Set Up

We’ll start with a directory called notes with a file inside called

1. Start Tracking a Directory With Git (git init)

By default, your changes will not be tracked. In order to tell git that we want to start tracking something, we need to initialize git in a directory.

timo@Tims-MacBook-Pro:~/notes$ git init
Initialized empty Git repository in /Users/timo/notes/.git/

This means git now HAS THE ABILITY to track changes in the notes directory. This does not mean that git is tracking anything yet. Git is now prepared to track activity in the notes directory

NOTE: If you don’t see this message when you try git init, it means you have not set up git on your computer.

Things to Note

1. You only need to initialize a directory once in order to track everything else inside of it.

For example, if I typed this while in the essays directory:

timo@Tims-MacBook-Pro:~/essays$ git init

Then every file inside that directory, regardless of how deeply nested, would be available for git tracking.

Do not run the git init command more than once in the same directory or in child directories of the directory you initially ran it from. It will never be the answer to the problem you are facing

2. Empty directories are not tracked by git. Therefore, if you create a directory but there's nothing inside of it, git will ignore it. Git will only track it when there is a file inside of the directory.

3. What happens if you accidentally initialize git in a directory where you didn't intend?

When you type git init, a directory called .git is created inside of that folder. You can't see this folder using the ls command since it's a hidden folder. Everything that starts with "." is hidden. Instead, you can type ls -a which will display all hidden and visible files and directories.

In an git initialized directory, you'll see a .git directory. To remove git tracking, you would type:

rm -rf .git

This removes the git directory, and you are no longer using git to track your project. If you accidentally run git init in your home directory, and start tracking most of the files and directories on your entire computer, then remember to run rm -rf .git from your home directory. One way to tell if you've accidentally initialize git in your home directory is to first go home by running:cd ~ and then run: git status. If you see files being tracked but not staged for commit, then you need to remove the .git folder as layed out above.However, if your terminal returns:fatal: Not a git repository (or any of the parent directories): .git, then you are all good.

2. Check the Status (git status)

When you want to see what git is tracking and the current status of files, you can use git status:

timo@Tims-MacBook-Pro:~/notes$ git status
On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)

nothing added to commit but untracked files present (use "git add" to track)

No commits yet means that we haven’t asked git to save a version yet. You can think of a commit as a snapshot of your work at a certain point in time. In the Google Doc, each save point was a commit. So far, we have no commits for our notes project.

Untracked files refers to the fact that even though we initialized a git repository, we haven’t started tracking anything yet. It lists the files that are available to track. (Also note “untracked files present” near the bottom).

Things to Note

You can type git status as many times as you want, whenever, wherever. It it a safe command that will not change anything about your tracking.

Let’s talk briefly about this diagram from the git documentation. This diagram shows what you can do after you have initialized git:

Git Workflow Diagram

3. Add a File to Track (git add <filename>)

Let’s add one of the files that we want to track to the staging area. Google’s dictionary defines “staging area” as “a stopping place or assembly point en route to a destination”. If you’ve ever run a race, you know that the staging area is the place where all of the runners gather before the race begins. It’s a place to make sure everything is good to go before continuing on.

We will add our file to the staging area.

timo@Tims-MacBook-Pro:~/notes$ git add
timo@Tims-MacBook-Pro:~/notes$ git status
On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

  new file:

Notice the “changes to be committed” section: It tells us that we have a new file,, that is ready to be committed. We can say that the file is in the git staging area. That means no changes are tracked yet, but we’re ready to take a snapshot of it (we’ll do this next).

This may seem silly right now, given that we only have one file – why not just commit the file? Why do we have to add it first? Let’s take a small detour.

4. Take a Snapshot in Time (git commit -m <message>)

Now that our file is in the staging area, let’s tell git that we’re ready to commit (take a snapshot of this moment to save). It’s good practice to use “Initial commit” for your very first commit in each repository.

timo@Tims-MacBook-Pro:~/notes$ git commit -m 'Initial commit'
[main (root-commit) b7654a6] Initial commit
 1 file changed, 1 insertion(+)
 create mode 100644

Now if I look at my git status, this is what I see:

timo@Tims-MacBook-Pro:~/notes$ git status
On branch main
nothing to commit, working tree clean

Let’s figure out on the diagram what we just did:

Git Workflow Diagram

5. Making File Changes, Adding New Commits, and Viewing Those Changes By Using (git diff <filename>)

Now that we have our initial commit (or snapshot in time), let’s make a change to one of our files.

We’ll open up Atom to make these changes - Do you have auto-save enabled?

Your working directory now has changes that differ from what our file looked like the last time we committed (or took a snapshot).

timo@Tims-MacBook-Pro:~/notes$ git diff
diff --git a/ b/
index e69de29..9ffd068 100644
--- a/
+++ b/
@@ -0,0 +1,2 @@
+Be kind
+Work hard

Then add your changes and commit them using an imperative verb that starts with a capital letter and a short commit message explaining what you did.

The basic git workflow is this:

  1. Make file changes - we’ll do this in Atom
  2. Check the git status to see what files are unstaged
  3. Check the git diff <filename> to see what changes have happened since the last commit
  4. git add <whatever file you want to stage>
  5. Check the git status to make sure the correct files are in the staging area
  6. git commit -m 'Message about your changes' to commit the changes

Try It: Git Together

At this point, we'll split into breakout rooms. The person whose name is first alphabetically will start by sharing their screen, unless this person already has significant git experience. Whoever is sharing their screen will be called the driver. Every other person in the room will be a navigator.

The driver will be the person typing the commands, but the navigators should be the ones who brainstorm what comes next or what to type. In addition to naming the steps, discuss why you are doing each step, or what exactly is taking place in each step.

If you are already comfortable with git, your challenge during the breakout is somewhat more difficult: your goal is to focus on your explanations, communication, and ability to gauge whether or not another person understands you.

  1. Get back to your home directory
  2. Create a new directory called to_do. Inside of that directory, create a file called
  3. Initialize git inside of the to_do directory so that we have git available to track changes.
  4. Before you check the status, predict what it will say. Then, check the current status.
  5. Add to the staging area.
  6. Make your first commit in this directory.
  7. Before you check the status, predict what it will say. Then, check the current status.
  8. Use Atom to add three separate tasks to
  9. Before you check the status, predict what it will say. Then, check the current status.
  10. Before you check the difference between your last commit and what the file looks like now, predict what it will say. Then, check the diff.
  11. Add the changes to the staging area.
  12. Before you check the status, predict what it will say. Then, check the current status.
  13. Commit the changes using a properly formatted commit message.
  14. Before you check the status, predict what it will say. Then, check the current status.

Done? Switch drivers and try the process again!

Things to Note: Oh no, my terminal is broken!

  1. It is highly likely you will make mistakes in the terminal. Do not fret, there are a few tools to save you when you inevitably receive unexpected feedback or behavior from the terminal.
  2. control + C shortcut will stop most terminal tasks and bring you back to your current directory with no harm done. Try this first when you encounter unexpected behavior.
  3. At some point your terminal will look like it does in the photo below. This is Vim land. Vim is a text editor within your terminal that is beyond the scope of mod-0. When you find yourself here, you can type: :q, which stands for quit in Vim, and then hit enter to exit Vim. Sometimes, if you've already typed some characters, you need to use control + Cin order to get to a point within Vim where :q or :qa!, which is the command to quit and abandon changes, will successfully exit Vim.

Mistakes in the terminal

Terminal Mistakes Screencast


Iteration (or looping for a specified number of times) is a process of repeating a task for each object in a collection. For each of the scenarios below, we’ll walk through step by step to demonstrate the concept.

Iteration in Real Life

These are examples that would be programmatically challenging because they would require a ton of steps, but are things that we do everyday.

Scenario Collection For each... Do this: Then:
Grading papers papers paper
  1. read through it
  2. mark the score on the top
repeat with next paper
Feeding animals animals animal
  1. bring the animal to the food bucket
  2. allow the animal to eat
  3. bring animal back to barn
repeat with next animal

Iteration in Programming

By “in programming”, we mean things that could be done, with relative ease, by a computer. Like crunching numbers.

Scenario Collection For each... Do this: Then:
Calculating max heart rate birth years year
  1. subtract birth year from the current year to get age
  2. subtract age from 220
repeat with next year
Formatting names names name
  1. capitalize the first letter
  2. lowercase all remaining letters
repeat with next name

Try It: Iteration in Real Life and Programming

Brainstorm a real life scenario that uses iteration. Fill out the table below and be ready to share.

Scenario Collection For each... Do this: Then:

Problem Solving + Pseudocode

The ability to critically examine a problem and break it down into smaller pieces is an essential skill of a developer that can be improved with practice. Breaking large problems into several smaller problems can help you in every step of the development process:

  • Pseudocode: Breaking apart coding challenges into steps is often referred to as pseudocode. This is done by writing those steps in plain English (or whatever language you speak), and then those steps, can later be converted to code the computer understands.

Pseudocoding can help keep your thoughts in order, especially helpful for when you may need to put a little research into HOW to accomplish all the steps involved. Further, pseudocode is an excellent approach to explaining code to your team because it is programming language-agnostic, allowing non-technical teammates, or teammates who work with different code/technology, to understand your ideas more easily.

Pseudocode - An Algorithm

Pseudocode often reads like an algorithm. Algorithms often read like recipes:

Psuedocode for Making a Cup of Coffee

- Organize all ingredients together
- Add water to electric kettle
- Turn electric kettle to ON
- Put coffee grounds in french press
- When water in electric kettle boils, turn to OFF
- Wait 30 seconds
- Add water to french press
- Put plunger over top of french press
- Wait 80 seconds
- Press plunger down
- Pour coffee into cat mug

Pseudocode Practice

On your own, write some pseudocode for how you would make a Peanut Butter + Jelly sandwich - remember, think about how you can break this “problem” up into the smallest parts possible to allow for the clearest instructions!

Pseudocode Breakout Demo

Watch as your TAs model how to engage in a discussion of technical content as they share their pseudocode for creating a sandwich!

Psuedocode for Technical Challenges

Take a look at the example of a code challenge you might receive as part of an interview.

Challenge: Write some code that will determine the number of vowels in a given word/string.

Below is an example of some pseudocode that could be written for the challenge. What are some things that stand out?

- Declare what letters are vowels - a, e, i, o, u
- Start vowelCount at 0 to track number of vowels in the word
- Look at first letter in the word
- Check if vowel
  - If letter is included in list of vowels, increase vowelCount by 1
  - If letter is NOT included in list of vowels, do nothing
- Move to next letter in word and repeat steps from Check if Vowel
- When there are no more letters left in word, return the final vowelCount number

“Good” Psuedocode

Before we go any futher, understand that it takes a long time to get proficient at writing strong psuedocode. However, here are some indicators of “good” psuedocode:

  • Each “step” could be translated into a line/few lines of code
  • Each “step” can translate into a Google search fairly easily, if necessary
  • The code considers “happy” and “sad” paths
    • What should the code do if things go well?
    • What should the code do if things don’t go as expected?

“When will I even use this?!”

Hopefully, A LOT! Psuedocoding can be a great process to employ any time you are “stuck” on what your program should be doing! Basically, if you can’t explain WHAT you want your code to do in your native language, there is literally 0% chance you’ll be able to write code to accomplish that task!

Additionally, psuedocoding comes in handy during technical interviews and code challenges for when you are applying for jobs. Interviewers want to see how you can break complex ideas down into language that everyone can understand - remember, as a developer you will often be working with non-technical colleagues in marketing, sales, etc. and hiring managers want to know that you can communicate with them!

Practice: Problem Solving

Write your process for changing a flat tire on an automobile!

On your own

  • How can you break this problem down into smaller chunks or sub-problems?
  • What steps are needed to get from the initial data (input) to the desired end result (output)?

    In groups

  • In groups, take turns sharing your psuedocode
  • As a group, come up with a Team Pseudocdoe that can borrow parts from all the different group members!

    Share Outs + Walkthrough

Everyone should read this article at some point after class - note that it’s written in Ruby, but again, focus on the process


Understanding git and the workflow can be tricky at first; however, this pattern is one that you will come to memorize over time. As you are memorizing the steps, be sure that you know what each step does.

Today (and during Mod 0), we’ll just be moving forward in time using git. We won’t learn how to go back in time, but it’s important to understand and main making small commits before adding in new git functionality.

We do not expect you to have these steps and reasons memorized right now. You can always reference back to this tutorial (or other tutorials that you find online). The more you practice, the easier it will become.

Check out this great resource from built by Turing instructor Amy Holt:

SSH Check

In your terminal (use shortcuts if you can) check if your ssh keys are configured correctly by running the command below and seeing a success message:

$ ssh -T
Hi <your_username>! You've successfully authenticated, but GitHub does not provide shell access.

If you get an error message instead of the success message shown above, reply in the Slack thread with your output after running the $ ssh -T command!


Find the homework in your Mod 0 Project Board. Post in the Mod 0 Slack channel if you’re stuck (and don’t be afraid to help each other out).

Asking questions

Now that we’re working on some more technical subjects, be sure to provide as much context as possible in your slack questions. They’ll help you get an answer faster and that answer will be more accurate. Use this guide to ask good questions!