Suncode 2017 Reflections

Every year I look forwards to the Suncode hackathon, organized by the Powerhouse solar incubator in Oakland, CA. Participating in the 2015 Suncode hackathon gave me the courage to help organize the Cleanweb Berkeley hackathon, and taught me an immense amount about the solar industry.

This year, Jon Mather and I were interested in implementing our recent research paper on distributed energy optimization, and recruited the skills of Tanyoung Kim for data visualization. With a team and a project idea, I felt much better organized than in any previous hackathon I’ve attended.

Unfortunately those grand plans didn’t fall into place over the course of Saturday, and our team walked away without an award or honorable mention (but with some useful contacts for developing the project). Much like at my last Suncode, the team wasn’t able to stitch together the individual contributions into a coherent whole during the allotted time, and we presented just Tanyoung’s data visualization. Someday, I’d like to see my code end up in the product that’s presented at one of the Suncode hackathons!

While I was much better prepared this time than for previous hackathons, I clearly still have a lot to learn.  The following are some of the things that worked -and didn’t- from this year’s Suncode:


  • Good preparation. Much better prepared, with a good understanding of the technical tools which I wanted to use and practice during the hackathon. A good website template and good repo made me feel comfortable when we started.
  • Learning new skills. I learned a lot about triggering events between the front-end and back-end of a website in Flask, both through Ajax-style requests and through server-sent events.
  • Flexibility in storytelling. We quickly adapted our story and pitch to reflect the feedback of the mentors, dropping any mention of blockchains.


  • Sketch out the stack and wireframe ASAP. Tanyoung and I ended up with separate development environments which couldn’t communicate with each other- scuttling our chances for a coherent demo.
  • Hardware is hard. Make it a “nice-to-have” rather than “need-to-have.”  I spent ~2 hours just troubleshooting network connections for our WeMo light bulbs and switch. When we moved locations for the final demo, communications latency jumped to ~20s making our demo incoherent.
  • Be a strict taskmaster. We expected that coding the math in Cvxpy would take about 2 hours; when it was less than half done in that time we should have stopped work on it so that Jon could work on the story and front-end.
  • Be flexible.  Don’t get stuck on one vision of what you’d like the system to be, and be continually ready to
  • Don’t try anything new. If you want a polished product, you won’t also have the time to learn new skills.  Be sure that everyone’s familiar with the tools, development environment, and technique when you walk in.
  • Or… Only try something new. Some of the joy of a hackathon is to try something risky out with no consequences to failure.  Feel free to try something you’ve never done before, with the full understanding that it might fail and you might have to fall back to a Powerpoint deck!

I was much less stressed about technology this time, and instead my stress came from time management and communication issues. Definitely highlights areas I need to improve for the future!

Photo of team workspace

Our team busy hacking, with WeMo & Sylvania lightbulbs, a fan controlled by a WeMo switch, extra monitors for coding efficiency, and extra laptop for Ethereum networking, and lots of caffeine.

Leave a Reply

Your email address will not be published.