Source Code
Ashton Wiersdorf is a senior at Maeser Prep Academy
I remember the very first computer program my dad taught me to write. He took me to the FreeBSD server that lurked in the craftroom closet. This time, instead of teaching me how to edit files or send email from the command line, he showed me a simple one-line program that generated a random number.
Within a few years, I grew from one-line programs to much larger programs that made use of iterative algorithms and recursive data structures. During this time, my cousin Alex became interested in programming. We happily hacked little projects together until we both landed a summer internship at my dad’s company.
Our knowledge and abilities exploded.
The autumn after our internship, Alex and I were both enrolled at Karl G. Maeser Preparatory Academy. Within the first few weeks, our science teacher required all of her students to perform a science experiment which we could enter into the school science fair. Alex and I obtained permission to work together. For our project, we wrote Scheme interpreters.
A Scheme interpreter is a program that parses and executes Scheme programs. An interpreter is like a pianist, and a Scheme program is like a piece of music. Without the pianist, the piece of music is meaningless. However, by interpreting the notes on the score, the pianist can make music.
We worked frantically for the next several weeks. After staying up until three in the morning, we barely made the class deadline.
A week or so later, the Physics teacher reminded us about the science fair that night. I nearly fell out of my chair. Alex and I wanted to participate in the fair, but we had completely forgotten.
I arranged for Alex to come home with me after school. As soon as we got to my house, Alex hopped on the computer and started hacking out little blurbs for our poster. I ran to the store and picked up a poster. Alex had a laptop that we were going to use to demonstrate our project. Just before we left, I copied our project onto the laptop.
We were several minutes late. Fortunately, the judging hadn’t started yet. We set up the poster and the lap top. Everything was ready.
Then our program didn’t run.
Something was wrong with the interpreter we were using.
We tried accessing the school’s Wi-Fi, but it was locked. We tried connecting to a Wi-Fi network we knew the password to, but it was out of range.
Panicked, we explained the situation to one of the teachers. She kindly lent us her phone to use as a Wi-Fi hotspot, and our demonstration was saved.
I wasn’t expecting to win anything. After all, we had just hacked our poster together at, quite literally, the last minute. However, we placed third and were able to move on to regional competition.
In preparation for region, we made a bigger and better poster, and we practiced. At the regional competition, judges did not assign rankings. They merely selected candidates who would go on to the state level. Every student from our school qualified.
Alex and I continued to refine our presentation. We made our source code publicly available on GitHub (a code sharing website). We tailored the flow and depth of our presentation for varying experience levels we anticipated encountering in the judges. We printed out selections of our source code for judges to view.
At the science fair, three judges evaluated our project. After the final judge left our booth, Alex and I breathed a sigh of relief. We had prepared almost perfectly. We had created three distinct presentation flows for varying tiers of experience. Each of the judges fit one perfectly. After the science fair, we had to wait until the awards ceremony that evening to know how we did.
Alex and I learned much from what we did well on this project. We coordinated our efforts effectively, and we made a good team because we both were willing to sacrifice time and sleep for the project. We made some mistakes too; procrastination and insufficient communication were the primary culprits. In the end, however, we knew we had made a good product.
We won first place.