This summer, I was a part of Summer of Code working with Jason Griffey on his Berkman Klein project, LibraryBox.

I wrote on Medium about parts, but I wanted to reflect here on some of the things that I learned.

First, I’d like to say that this summer was a blast. The end was a bit hectic, since I’d gotten right into the thick of getting everything pinned down when I went back to school at the University of New Mexico (shoutout to my burqueno peeps!) and ran into professors that like packing the first few weeks with content. When I started working on LibraryBox this summer, I was more or less familiar with its usage. I’d played around with PirateBox and getting things working on a laptop previously, having gone to my fair share of DefCon events where I saw them pop up for adhoc file sharing. There’s a lot of great stuff that LibraryBox and PirateBox do that I wanted to help make better.

Lesson 1: Real, working hardware and such is the greatest debugging platform.

When I picked up porting it to the raspberry pi, I ran into a lot of little tiny issues here and there. As a note to future people doing things like this: Be ready to do some footwork when moving from an embedded platform like OpenWRT onto a platform like the rpi. There’s subtle differences and I can’t stress enough that until I was about halfway through the summer, I really didn’t know what I was doing. Learning that getting things running on real hardware as fast as possible is your best bet to make sure that your life is going to be just fine. Once I got my software running on the pi, I had a lot more fun getting the project moved forward.

Lesson 2: A day you don’t code isn’t a day wasted

It’s easy to think that a day you write zero lines of code is a day you’ve wasted. The reality is that this is a terrible way to handle the situation and will only drive you to the edge of burnout before you realize what you’re doing. Take days to think, work on something different, and even just not work at all. All-nighters are not worth it unless you have a good reason and the more I tried to force myself to work the less I got done.

The reality of the matter is that taking a day to work out notes and lay out design on paper can be the best day you get things done. I did a lot of “go to starbucks and sketch out the problem I’m having” and my notebook is as a result filled with pages like this:

Those notes were a few hours of thinking, sketching out ideas and getting things down on paper. Some notes I took while on a plane, some notes I took at dinner, other times notes were the byproduct of someone mentioning something.

Lesson 3: You have people around you who can solve your problems.

Software dev isn’t done in a vacuum. It’s tempting to hunker down and hide away and not talk to people, but there’s a lot of things that your friends and collegues know that you don’t know they know. I learned that one friend of mine was currently dealing with some of the same container problems I was facing, but in a slightly different context. This helped me find the source of one of my woes and hammer down what I really needed to solve. I had been burning for a week trying to figure out an obscure problem with systemd and how to make chroots work, then a friend mentioned systemd-nspawn and the skies opened up and this happened:

This was a good week of me being unhappy with my work, getting progressively more and more frustrated. Ten minutes of conversation solved a week of me hiding from people and just beating at the problem. It was bad enough that I hadn’t bothered to really mention it to my partner, who was a bouncing board for so many other things this summer.

Wrapping up

These were my experiences. My mentor helped me get on track when I had been wavering, helped set up a schedule and my partner really kept me in line. We build software not in isolation but by looking at others for help. I hope to be back next ear for more of this and get to know more people as I refine my skills! This summer had challenges, things that I didn’t expect. Did I hit every goal? Not by a longshot. But I hit the important goals, getting somewhere that I felt was more than just a proof of concept and more something that can be actively demoed soon.