Sunday, March 20, 2011

Lessons from gonzo programming

I recently experienced writing code under a looming deadline for the first time. After applying for the Cascadia Innovation Fellowship, I received a request for my résumé and two code samples due the following day.

The request described two pieces of code and asked me to implement them. I started immediately, dispatching the first with little effort and working on the second for a couple hours in the evening. Then, I unwisely decided to stay up to finish my second sample. I “finished” the code, “tested” it, and, satisfied, went to bed.

The following day, I worked on my résumé for most of the day, looking at the code again late in the evening. A simple test revealed a fundamental flaw in my algorithm, and I stayed up until 2:30 AM rewriting the algorithm, submitting my code only 30 minutes before the deadline.

I feel pretty good about my final code, but I didn't enjoy staying up late and coding frantically.

I learned a few valuable lessons worth sharing:

  • Test thoroughly. If you're not trying to break your code, you're not testing.
  • Prioritize. My résumé contained virtually no information I hadn't already submitted through my original application, yet I spent precious hours polishing it obsessively. I knew that the quality of my code would be the most important factor in my application, but I left my coding until the last minute.
  • Use the obvious solution first. When I first considered the second piece of code, I skipped over the obvious solution in favor of a “faster” and “more general” solution that didn't work. I made the classic mistake of trying to solve a recursive problem non-recursively without first implementing the intuitive solution.
  • Use git. After identifying the fatal flaw in my original code, I attempted to solve it with a set of small changes throughout the program. After working on the algorithm for about an hour, I rediscovered the obvious solution which was based on my original code. Thanks to git, it was easy for me to stash my changes in a new branch and resume work on my original version.
  • Don't use C++. Because the prompt implied that solutions should be written in Java, I started working in C++ and asked if that would be OK. Instead, I should have asked if I could use Python: both of the challenges would have been almost trivial in Python.
  • Never be without Programming Pearls. I left my copy at my dorm when I went home for spring break, so I couldn't refer to it to help me solve the problem. From now on, it's not leaving my side.