The Moment Between Flips

In today’s fast paced world, pancakes are a great way to slow down. Each pancake needs to cook for a minute on each side. During that minute, you have to stay close – you can’t go off and do something else. It’s a great time to think. The mind wanders about this and that as the bubbles rise to the surface of the pancake. It’s a peaceful moment with nothing to do except wait for the next flip.

I cherish these pancake moments. I love to image that I’m living in the country and I’ve just completed the morning chores – nothing to do but think. I think about how nice the weather is and how interesting it is to be alive.

Today, I thought about how much we consume. Why do I feel the urge to browse Amazon for new things? Why isn’t what I have sufficient? I am addicted to that small burst of happiness when the next Amazon package arrives. But like pancakes, there’s no need to rush – slow down and enjoy the current moment.

Collectibles: Use Them or Lose Them

When I was a child, I was spoiled rotten. My parents had a dual income that they apparently chose to spend on toys and collectibles for my brother and I. We had a huge room above our garage dedicated to only our toys. In retrospect, it was ridiculous – but of course we loved it.

As I grew, things changed. My parents got divorced and we had to move. All our toys and collectibles went into boxes and moved with us as both my mom and dad changed houses every year. Those boxes stayed with my parents until I graduated college. Then, I chose to take everything my parents were storing when I moved to Silicon Valley.

Turns out, having those boxes sit around is a huge burden. They are always at the back of my mind and any time I try to make a big decision, they get in the way. “Should I get a rug to bring the place together? No, I should go through the boxes first.”; “Should I get a bike to commute to work? No, I should go through the boxes”. The boxes give me some form of decision paralysis, so I am finally deciding to go through them.

The majority of the boxes are filled with old toys and stuffed animals. After reading Marie Kondo’s The Life Changing Magic of Tidying Up, I decided it would be best to donate these things to Goodwill. Now, I’m left with collectibles and gifts from relatives – a lot of them are still in their original packaging. These are harder to deal with: they’re probably worth some money, they have a nice handwritten note on the packaging, and they’re from someone who loves me.

But I’m not interested in these collectibles. I’m not going to display them, I don’t want them, and they’re taking up space – both physically and mentally. I almost feel cursed. Why did my parents choose to keep these collectibles wrapped up for twenty years? Why am I dealing with them now? Did they feel too guilty to get rid of them, but too scared to display them?[1]

I’ve decided to do something with them. For the collectibles that I actually enjoy (there are only one or two), I’m going to unwrap them and display them. They’re not giving me any happiness sitting in a box – they’re much better on display where I can see them everyday. Most importantly, I’m going to throw away the box.

For the collectibles that I don’t enjoy, I’m going to take a quick stab at selling them on eBay and Craigslist. If they don’t sell in a couple weeks, I’ll donate them. I’ll forget about them a few weeks after and I will be burden-free.

I’m going to start applying this philosophy to other collectible-like things: stickers, books, greeting cards. If they’re sitting in a box, use them or lose them.

1 My parents have always had a big garage: I wonder if putting the boxes in the garage had some sort of “out of sight, out of mind” effect and they were completely free of this burden.

Organizing a Small-Scale Programming Competition: Question Writing

As soon as I joined the committee, I got started working on the next competition and learned about the processes in place. We constantly worked to improve them. In this post, I will talk about old processes, why they existed, and how we attempted to improve them.

Writing Questions

Writing questions for the competition is the most important step in the competition design process. In our committee, question writing was done by a designated group of committee members. They would write a rough-draft of their question, a small sample, and potential background stories. After a few weeks, the committee gathered to review all questions and narrow them down to the 15 we would use for the competition. To do this, we gave each question a difficulty rating of easy, medium, or hard. We then eliminated questions until all that remained were the 15 we would use, where the majority of them were “medium” difficulty.

Writing Test Cases

Of course, we also needed to create a collection of test cases to test contestant’s programs against. The test cases consisted of both INPUT and OUTPUT. Creating these test cases by hand for each problem posed a problem: crafting inputs was easy, but doing the work to calculate the expected output by hand was challenging. Further, we wanted a fairly large number of inputs to catch any corner-cases that contestants may have missed.

Sample Cases, Input / Output, and Method Stub from the Fall 2014 competition

Another challenge was test case formatting. Test cases had to be fed to contestant’s programs, whose output then had to be verified. Some of our test cases were also pretty complex (e.g Given a 2D array which represents one map, a 2D array which represents locations of hazards, find a path to the square with coordinates (X,Y)). Contestants definitely shouldn’t have to write this parsing code and instead should only focus on solving the problem in a pre-defined function stub.

Thus, the following problems had to be solved:
1. Given hand-crafted input, auto-generate output that we would use for judging contestants.
2. Provide the contestants with programs that already contained input-parsing and output-formatting logic. Contestants would simply complete a function stub.

Behold: “Template Writers” and “Solution Writers”

We solved the problem by having committee members be “solution writers”, who would act just as the contestants. For each problem, a “template writer” would write a template program that parsed input/output. Solution writers would then use the template and implement the function stub. As long as there were 3-or-so solution writers for each problem, this went very well. After everyone was finished, input could be added into a single file and provided to the solution writer’s programs. If all their outputs agreed, this input/output combination would be considered a new “test case”.

Eventually, we settled on a standard input format (separate test cases were delineated with newlines, components of each test case were determined by the template writer) and a sort-of standard template pattern.

Below is a Java template and case input for a problem in Fall 2014:

import java.util.*;

public class Problem4 {

  //Parameter(s): char ch - the character to be searched for in the String
  //              String phrase - the String to be searched through
  //Return:       int - the number of character triples in the String
  public static int spyingOnTriplets(char ch, String phrase) {


    return 0;

  /////////////////////DO NOT MODIFY ANYTHING BELOW THIS LINE///////////////////
  public static void main(String[] args) {
    Scanner in = new Scanner(;
    ArrayList<String> input = new ArrayList<String>();
    while (in.hasNext()) {
    for (int i = 0; i < input.size(); i++) {
      char searchLetter = input.get(i).charAt(0);
      String searchString = input.get(i).substring(2);

      System.out.println(spyingOnTriplets(searchLetter, searchString));


d ddidddd
f ffffffluffffffy
f fluffyyyyy
z heyhowyoudoin
o ooooo
o oooo
b blblbl
b bbb
c c-c-c
' '''
- -----
p chicken


At the time, we continued writing inputs and templates by hand. However, we put a lot of effort into PCFramework, which was a collection of shell scripts that would allow all testing of test-cases to be handled automatically.

As an example, basic workflow looked like:

cd BPCFa15/Solutions/dev # Move into the solution writer directory
cp ../Templates/ Brandon/ # Move the template into my own workdir
vim Brandon/ # Fill in the function stub with my solution
./ 1 Brandon # Test my solution against "sample input" and "corner input", which are hand crafted
./ 1 Brandon Dylan Marisa # Compare outputs of solutions and verify they are the same
cp Brandon/problem1.out tests/problem1.out # Move Brandon's output into the official tests folder

This allowed us to have “Sample inputs” (sanity inputs whose outputs were provided), “Corner inputs” (Difficult corner cases whose outputs were hand-crafted), and “Generated inputs” (inputs that we created by hand but whose outputs were generated by solutions).

Other Benefits of Solution Writers

On the surface, solution writers provided the competition with usable outputs. In addition, the process of crafting solutions by hand provided us with insight into other metrics, such as how difficult the problems really were and how easily they could be understood. More than once, we revoked a question from the question pool after we discovered that no solution writers could agree upon a solution.

On one occasion, we discovered that one of our problems actually boiled down to a difficult scheduling problem and none of our solution writers could optimally solve it. Obviously, this question was pulled.

A “golden solution” for the above problem:

import java.util.*;

public class Problem4 {

  //Parameter(s): char ch - the character to be searched for in the String
  //              String phrase - the String to be searched through
  //Return:       int - the number of character triples in the String
  public static int spyingOnTriplets(char ch, String phrase)
    int count = 0;
    char[] characters = phrase.toCharArray();
    for (int i = 0; i < characters.length - 2; i++)
      if (characters[i] == ch &&
          characters[i+1] == ch &&
          characters[i+2] == ch)
    return count;

  /////////////////////DO NOT MODIFY ANYTHING BELOW THIS LINE///////////////////
  public static void main(String[] args) {
    Scanner in = new Scanner(;
    ArrayList<String> input = new ArrayList<String>();
    while (in.hasNext()) {
    for (int i = 0; i < input.size(); i++) {
      char searchLetter = input.get(i).charAt(0);
      String searchString = input.get(i).substring(2);

      System.out.println(spyingOnTriplets(searchLetter, searchString));




Supporting More than Java

The usefulness of these verification tools quickly became evident. Since verifying inputs/outputs was now trivial, we could start supporting languages other than Java in our competition (as long as someone wrote a template and we had enough solution writers). Due to contestant demand, the first additional language we supported was C++.

At this point, our competition moved to HackerRank to manage contestant solutions and inputs/outputs.

Driving CA1 (PCH) from Temecula to Mountain View

I’ve been a Southern California resident all of my life, yet I have not once driven on the famous CA1 (Sometimes called “Pacific Coast Highway” or “Cabrillo Highway”). My recent move from sunny San Diego to Silicon Valley seemed like the perfect moment to experience the famous highway.

I planned the trip to take 2 days and I would drive a rental car with a trunk full of my dearest possessions (basically clothes and my computer). For a semi-leisurely trip, 2 days seems like the minimum (One could accomplish the trip in 1 day if they made no scenic stops, started early, and ate only on-the-go).

Leg 1: San Diego to UCLA

The CA1 does not actually start until Santa Monica. Thus, I decided that I would visit family at UCLA for the first portion of my trip. I took the usual commuter route (I-15N -> I-91W -> I-405N) and arrived in 3 hours. Unfortunately, I left San Diego around 10AM and got slammed with constant stop-and-go traffic once I reached the LA area.

Leg 2: UCLA to CA1

I originally planned to get lunch at Ike’s in Westwood, but could not find parking. Actually, I think that circling Ike’s block took more time than my visit to UCLA itself. Mid-day Westwood traffic is no joke. After circling once, I decided that I would hit the road and find lunch along the way.

Getting from Westwood to the CA1 is extremely simple. The I-10W dumps right into the CA1, so I simply took I-405S -> I-10W -> CA1. From there, the surroundings quickly shift from Santa Monica beach city to motels/restaurants to nothing-but-nature.

Leg 3: CA1 to Cambria

The hotel room I booked for the night was in Cambria, which Wikipedia notes as the midway point for the CA1. Getting there was no problem, albeit a little confusing since CA1 and 101 intermingle. (When in doubt, follow signs for 101N and CA1N, prioritizing those for CA1N). I eventually reached Cambria after a very beautiful drive. The CA1 was closed about 10 miles north of Cambria.

Of course, I had to make a stop at Hearst Castle.

Leg 4: Cambria to 26-Mile CA1 Big Sur

Since CA1 was closed just north of Cambria, getting out of Cambria actually required some backtracking. I took the CA1S toward 46E, which connected to 101N. I then had to take 101N until it reconnected with CA1. Luckily for me, this drive involved driving through some beautiful farmland. Getting stuck behind slow tractors was annoying, but the smell of ripe, in-season strawberries was probably my favorite part of the trip.

After following 101N for a couple hours, it reconnected with the CA1. The Big Sur portion of CA1 is not to be missed, so I took CA1 south for 26 miles. Along this route are beautiful ocean views, plenty of turnouts for pictures, and the famous Bixby Bridge. Of course, once I reached the end of the 26 mile stretch, I had to turn around.. but it was worth it. This stretch added about two hours to my journey, including stops.

The beautiful Bixby Bridge.

Leg 5: CA1 Big Sur to Mountain View

The final portion of my trip was driving up to Mountain View. It was getting late, so the sun was setting and traffic on CA1 was thinning. The ocean fog was rolling in, making for an even cooler drive. Along the way, I stopped at a lighthouse for pictures.

Eventually, I reached 92E which signs indicated “San Mateo”. I took it and followed signs to Mountain View. I arrived at around 7PM.

Organizing a Small-Scale Programming Competition: Background

My Story

Near the end of my first quarter at UCSD, I began seeing posts on Facebook which
advertised a “Beginner’s Programming Competition”. Students who have not yet
taken any upper-division Computer Science courses could solve small programming
questions. Whoever completed the most in the shortest time would be given a
prize. I’d been programming long before college, so of course I’d sign up.

Advertisement for Spring 2014 Competition

The flyer for the first competition that I helped run. I got a BitTorrent T-Shirt

I arrived and was given a dedicated workstation and a packet of questions. We
had three hours to solve as many problems as we could using Java. All
submissions were to be sent through PC2 and three winners would be announced at the end.

I learned three things that day:

  1. A competition environment makes programming very stressful and much more
  2. I was not the only one who had been programming “long-before college”
  3. I was hooked.

I did not win. Heck, I didn’t even place in the top 10. But I had a blast.

Next quarter, I teamed up with a long-time friend and we ended up placing in
the top 5. I was satisfied and immediately signed up to join the committee. I
would spend my entire college career working to improve the competition.

What Was So Great?

Obviously, I had a good enough time while competing to justify joining the
committee. Indeed, the competition did a lot of things right.

  1. The beginners-only spirit of the competition made it easily accessible for
    me. It also thoroughly proved the joys of programming without intimidating
    me into my own self-loathing.

  2. All of the questions had cute backstories and the competition had an
    overarching theme. For my second competition, all questions followed an
    unnamed chef as he encountered difficult problems in the kitchen. This
    really helped lighten the mood and made it enjoyable.

  3. Balloons. There were people whose sole job was to deliver balloons to
    contestants every time they solved 2 problems. Not only was this a morale
    booster while struggling, but it was also fun. Some even had little faces
    drawn on them.

  4. The competition was run by students, for students. Something about
    partaking in a competition designed by my fellow students made the problems
    seem even more solvable. (If my TA wrote the question, there must be an
    easy solution!
    ) Further, the competition was not too corporate. Sure, there
    was a small corporate sponsor, but they only provided some prizes to the
    winners. Definitely nothing too in-your-face.

The question packets for each year I was involved in the competition

The question packets for each year I was involved in the competition.

What Could Be Changed

When I first joined the committee, I didn’t think much about improving the
competition. I simply wanted to help build it. Of course, I spent a lot of
time building tools to help create the competition, but it wasn’t until later
that I realized there was still work to be done. Most of this work was realized
because of post-competition-feedback we got from our contestants.

The biggest complaint was that contestants could only program in Java. Intro
computer science classes taught in Java, but many contestants were coming in
with pre-existing knowledge of Python and C++.

Some other contestants complained that prizes were lame. It was true. It cost
money to run the competition, so we asked programming-related companies to
provide us with funds and in return they could provide their latest tech
(read: advertisements) as prizes to the winners. Unfortunately, this meant that
companies often sent branded glasses, t-shirts, and stickers. No one felt good
about taking first place in a 3 hour competition only to receive a sticker.

Finally, the logistics of running the competition were a mess. Sure, we had
PC2 to help facilitate checking correctness, but volunteers were running around
like crazy delivering balloons, answering contestant questions, and ensuring
that no one was cheating. This meant that volunteers ran to the “control room”
to get a balloon, looked at a whiteboard to see who needed a balloon (the
whiteboard was managed by someone repeatedly refreshing the scoreboard), and
ran the balloon to the contestant. Over and over again.

I absolutely loved the competition and loved being on its committee even more.
In the next posts, I’ll detail how we decided to manage the logistics of
creating and running each competition. Hopefully they are useful to some other
competition would-be-designers.