Wallis' Blog

My Journey from Wall Street To & Through Flatiron School

Binary Search Trees

What are “binary search nodes”?

Binary search nodes are the components of a binary search tree (“BST”). What is a BST? Going with the old adage that a picture is worth a thousand words, I thought this image from Wikipedia was very helpful:

binary search tree

Any circle in this drawing is a “node”. There are a couple things you’ll notice about a BST:

  • Pick any node in the tree, and you will see that:
    • All nodes in the chosen node’s left subtree are LESS than the chosen node
    • All nodes in the chosen node’s right subtree are GREATER than the chosen node
    • Each subtree is itself a BST
    • Each node is unique

    There are a few terms to konw when talking about BSTs:

    • Root - the base of the tree, i.e. it has no parents (in the picture above, 8)
    • Leaves - the nodes that have no children (in the picture above, 1, 4, 7 & 13)
    • Size - total # of nodes (in the picture above, size = 9)
    • Depth - the depth of a particular node is # of steps between the root node & that particular node (in the picture above, the depth of node 6 is “2”). Note that the depth of the root node is zero
    • Height - the height of a tree is the depth of the deepest node, aka “the depth of the tree”

    The maximum number of nodes in a tree is equal of 2^(h+1) - 1, where h = height of the tree

    This highly structured format makes BSTs an efficient way of searching or sorting data.

    Other names for BSTs:

    • Ordered binary tree
    • Sorted binary tree

Learning Git the (Almost Kind of) Fun Way

I started learning to use Git about a week after I purchased my first-ever Mac. I was a true novice. Git seemed like a blizzard of words disconnected from their traditional definitions – merge / commit / rebase / push / pull all took on new meanings but I didn’t feel confident in my grasp of the subtleties that seemed to make the difference between an error message (or worse, messing up work flow) and a successful result.

Then my Flatiron School classmate (and fellow Wellesley alum!) Jane Vora posted an awesome graphics-based intro to GitHub that made Git start coming together in a much clearer way for me:


I love the graphic representations of what happens when you type in different commands. It’s like a (really nerdy) virtual race car driving game - exciting & fun, but even if you totally crash and burn, no one (or their code) actually gets hurt.

Get yourself into a pickle? (Or more accurately, a spaghetti-bowl-like mess of bungled commits, rebases, etc.?) No problem, just type reset and give it another go.

Some of my early points of confusion with Git were (answers below):

  1. What pushes you forward one step vs. staying in place?
  2. When you’re on a particular branch and invoke a command, are you doing that action to the branch you’re on or the branch you’re invoking?
  3. What’s the difference between rebase & merge?

On #1, I thought the following 3 pictures were really helpful.

A project with one commit starts out looking like this:
starting point

Then, if a commit takes place, that moves the version forward one step:
after commit

Or, if instead you make a branch, you make a copy without moving forward one step:
after branch

Part #3 of the Introduction Sequence, “Branches and Merging”, helped me understand that
you merge a named branch INTO the branch you are on

Let’s take a look at the solution for this exercise, “Merging in Git”

$ git checkout -b bugFix    //creates a branch and names it bugFix
$ git commit    
$ git checkout master    //switches you over to master
$ git commit    
$ git merge bugFix      //merges bugFix into master (you were on master)

After you complete the second-to-last step, “git commit”, it looks like this – notice you are on master, as denoted by *
before merge

When you “git merge bugFix”, it merges bugFix into master (the branch you were on), and looks like this:
completed merge

Lastly, I thought the rebase exercise in part 1 of “Master the Rebase Luke” was helpful in understanding rebase. The problem starts out like this:
rebase exercise starting point

and your goal is to recreate a single, chronological work history that looks like this:
rebase exercise goal

My first solution worked, but was 7 more steps than the suggested 7 steps. I realized I was being redudant by rebasing both branches onto each other:

$ git checkout another
$ git rebase side
$ git checkout side    
$ git rebase another
$ git checkout bugFix    
$ git rebase master    
$ git checkout master    
$ git rebase bugFix
$ git checkout another
$ git rebase master
$ git checkout side
$ git rebase bugFix
$ git checkout master
$ git rebase another

I learned that when you have a command that looks like this…

git rebase [branch_name]
(where [branch_name] is a placeholder for any branch name)

Git will rebase the branch you’re on ONTO the branch [branch_name]

So I eliminated the redundancy and came up with a solution in 8 steps, still 1 step shy of the goal:

$ git checkout bugFix
$ git rebase master
$ git checkout side
$ git rebase bugFix
$ git checkout another  
$ git rebase side
$ git checkout master   
$ git rebase another

A few minutes of searching turned up this helpful page which taught me that you can name two branches in your rebase commands. The link above uses more professional-looking notation, but the format of naming two branches in your rebase command works like this:

git rebase [branch_you_are_on] [branch_you_want_to_rebase_onto]

So I was able to combine my last two steps into one:

$ git checkout bugFix
$ git rebase master
$ git checkout side
$ git rebase bugFix
$ git checkout another  
$ git rebase side
$ git rebase another master  // rebases another onto master

Summary Conclusion

Question 1: What pushes you forward one step vs. staying in place?
Answer: Commit pushes you one step further. Merge leaves you in the same place, and creates a copy that has all the work of the commit you branched from.

Question 2: When you’re on a particular branch and invoke a command, are you doing that action to the branch you’re on or the branch you’re invoking?
When you merge, you merge the named branch INTO the branch you’re on.
When you rebase and name one branch, you rebase the branch you’re on ONTO the named branch.
When you rebase and name two branches, you rebase the 1st branch (the branch you’re on) ONTO the 2nd branch.

Question 3: So what’s the difference between rebase & merge?
Answer: So this is one where I’m sure my understanding (and particularly when to invoke one vs. the other) will evolve, but I generally think of it as reconstructing a timeline and overlaying my changes (rebase) vs. mashing two branches together (merge).

3 Lessons From the Financial Crisis for Learning to Code

1) Don’t settle for a superficial level of understanding.

To really know something, you have to dive into the details, test your assumptions and understand what it is that you don’t know. It’s “easy” to listen to a pitch about subprime mortgage-backed securities and hear “enhanced yield” and “low risk” because of “product structure” and then think that you understand subprime mortgage-backed securities. It’s also pretty easy to do a few online tutorials about HTML/CSS, Javascript, Ruby, etc. and think that you have a decent understanding of what’s going on. In both cases you’d be wrong.

Diving into the material, understanding the details and challenging yourself to discover just how much you DON’T know is the hard part that ultimately leads to really, truly knowing something. Not that you will ever know everything, but you will know enough to be effective if you push yourself to dive deeper and commit the time and effort to really learn.

2) If you don’t truly, completely understand something…ask a question.

There’s a natural human instinct not to risk “looking stupid”. This usually results in fewer questions being asked. A room full of bright, hard-working people can listen to a presentation on something, a few questions will be asked, and at the end a number of people will still have a bunch of questions that have gone unanswered…because they were never asked.

I’ve been in a lot of investor meetings and brokerage meetings where assertions are made, explanations are given, and everyone sounds quite intelligent. But 99%+ of the time that something hasn’t quite made sense to me or added up and I asked a question, an interesting thing happened: either (most of the time) I learned something and it was a completely positive & constructive experience or (more often than should be the case) it became clear that the people making the assertions didn’t really have more than a superficial level of understanding themselves.

So what happened the rest of the time? The old adage “there’s no such thing as a stupid question” is definitely false, but….so what? Arguing that you shouldn’t ask a question b/c there’s some probability that it’s stupid is like arguing that you should never eat fresh fruits & vegetables b/c some of them are contaminated with e coli. The benefits of just doing it far outweigh the risks.

3) Work hard but keep yourself balanced & healthy.

During intense periods with long hours, a lot to do, and constant flow of new things flying your way it’s easy to get sucked into a relentless rhythm of too little sleep and too much caffeination. After existing in this state for awhile it starts to feel normal, even oddly empowering and exciting. But beware this feeling of turbo-charged productivity – that caffeine-and-adrenaline-fueled working frenzy can work fine for a short period of time, but it’s no more sustainable over a 12 week programming course than it was over a multi-month financial crisis.

The truth is, you’re not of much use to anyone (including yourself) if you’re amped up on a week+ of 4 hours/night of of sleep, 3+ daily cappuccinos and whatever Costco-sized package of caffeinated beverages you’ve polished off. Extreme exhaustion has been shown to have a similar effect on driving ability as intoxication, and quality of one’s work product is no exception - keep yourself reasonably rested and maintain some semblance of a “normal” rhythm, whatever that is for you.

Hello World

Hello world! This is my first blog post!