Three-Month 1up Retrospective

October 26, 2012

Over the past three months of tackling my 1up project I have learned which aspects of its design have worked and which haven’t. Rather than gritting my teeth and continuing to approach the remainder of the project in the same way, I want to admit my mistakes and make some adjustments.

First I’d like to mention what has gone well. It has been beneficial for me to think of a list of possible goals and topics at the start of the project. Taking the time to clarify to yourself what you’d like to work on is powerful, since we can otherwise get absorbed in our personal narratives and be caught off guard by life.

Next, it has been gratifying to share the method with others and see them run with it. I spoke at the Forward Tech Festival, at Madison Barcamp, and at the Madison Ruby conference, and each time felt a lot of energy and enthusiasm around the idea.

I have had fruitful interaction with experts. I divided the year into two-week learning intervals and generally the more productive intervals for me have been when I worked with passionate people at the start. Talking with Dale Sande about CSS style guides, or Matthew McCullough about Git workflow was really fun and I felt sorry when the scheduled times came to move on to new topics.

This leads me to my first mistake in designing this program: attempting two week topics outside of a meaningful project. In my history as a programmer I have learned most from projects that force me to learn technologies and techniques as a side effect. I start with something I really care about, like a startup idea, and the intrinsic hurdles naturally arise.

Some of my topics have been a bummer when I wasn’t able to connect with someone else to define a meaninful project. “Modern hosting” for instance. Although I attended a Linux User Group meeting about EC2, I didn’t find a project to sink my teeth into, and I spent that interval experimenting with Heroku caching techniques kind of at random. I think I’ve learned more about Heroku just by accident while trying to deploy real apps and encountering problems such as the Heroku read-only filesystem.

My next mistake exacerbated the problem of sterile topics, and that is the brittle schedule enforced by the program. Each topic is supposed to be exactly two weeks. As I mentioned before this has the good effect of creating urgency, but it can be super frustrating too. Stuff arises and interferes with the impeccable 1up timetable. Last week, for instance, I put in extra time at work to get a project back on deadline. Losing a week on a two-week 1up topic discourages me.

Another problem with assigning myself a series of topics is that they tend to be too specific and exclusionary. It’s hard to cowork with people when you’re locked into a very specific topic. For instance, declaring that “I’m doing only JavaScript now so I shouldn’t work with someone on their project unless it is JavaScript intensive.” Odds are lower that you’ll find someone who is not only interested in working with you, but can schedule the coworking in the short term, and is aligned on exactly the topic you’re doing. I would now advocate getting out of the office and being more flexible to work on cool stuff that might be surprising for you.

So my major lesson is this: I can and should plan what I want to do, but it’s foolish to plan up front exactly how I’ll do it. Rather than listing a series of lifeless technologies to check off my list, I should set goals of the things I want to create, and how I want to help people. It’s inevitable that creating a technological product, for example, will entail learning technology.

Considering my goal, then, what is it I want to accomplish? I started 1up initially by saying, “I want to be a world-class web developer.” That analysis isn’t exactly fundamental. Columbus didn’t cross the ocean in order to be a good sailor; he was a sailor in order to cross the ocean.

To be continued.