Why I Started Programming

Taking an "Intro" to Matrices Course

When I was in 11th grade back in 2014, one of my school's most brilliant wizards teachers, Dr. Gadbois, decided to create an impromptu 6-person elective course on Markov matrices, using the kid game Candy Land as our real world example of how the concept shows up in the wild.

The course objective was to explore a few topics and publish our findings in a math journal:

• the average number of moves to finish the game from any square for one player
• the average length of the game for any number of players

The Problem

We knew immediately that deriving formulae to solve these problems would be manageable. In the grand scheme of things that would be the easy part.

The bottleneck would come afterwards.

In order to concretely solve our two research topics, we were somehow going to have to operate on stupidly huge matrices¹ in order to compute the actual numeric values returned by our formulae – without committing any math errors along the way.

Initial (Bad) Ideas

I fully understand that what I'm about to tell you will sound outrageous, especially to those of you who have been writing software for years like I have.

But in hindsight, attacking our problem domain programmatically *spoiler alert* wasn't even on our radar at first. Think about the context:

1. We signed up for a math class...
2. And, prior coding experience wasn't expected!

I confess – believe it or not, the original plan we came up with was to solve the problems by hand.²

We brainstormed endlessly trying to devise ways to finish all those gigantic operations with just six students. I'll never forget a hilarious moment where we almost went out and bought several rolls of large graph paper the size kindergarteners use to hand-paint turkeys on thanksgiving.

In the end, manual calculations at this scale proved impractical. On top of being error-prone, this strategy would have taken more time then our schedule permitted because it required that we assign at least two people to each unit of work.

We had uncovered – and were forced to accept – the limitations of relying solely on our mathematics toolkit. It was a bitter pill to swallow.

Java to the Rescue

In light of these constraints, the potential of our research project began looking pretty bleak.

It would be impossible for us to perform a practical analysis and draw conclusions without actual numeric results. The entire project would be theoretical and, therefore, far less interesting and useful. In the worst case scenario, we might not have been able to find a journal willing to publish the paper, even though our formulae were mathematically sound and beautifully typed out using LaTeX.

Fortunately, Dr. Gadbois was able to get us back on track by calling in a favor:

In what felt like an instant, he whipped up a ☕ Java program modeling the Candy Land game board and implementing each mathemtical solution we crafted.

The Rest is History

Garret's programming heroics changed the tides for us. Not only was his approach several orders of magnitude faster than our hand calculation idea – i.e. a few hours of his free time vs. months of toil – his approach was also far less likely to generate inaccurate results.

This was the eye opening moment that inspired me to start learning how to code.

Learn More about the Project

• Read our paper, titled Mr. Markov Tours Candy Land: Available on Research Gate

• Publisher: The UMAP Journal 35.1 ©2014 by COMAP, Inc.

• Press release: Page 3 Article in Inside MUS