Hack Day Reflection

In the Hacker School Manual, reflection is listed as a trait of an awesome hacker. I seem to recall another blog post of theirs mentioning that it’s part of their daily recommended structure. I can’t find that post right now, so I’ll save that for another day.

Today, I spent the day working on a chat app that I plan on using as a demo for my Backbone knowledge. I barely got into the User model. Here are a few reasons why, ordered by impact:

  1. Upgrading RVM and Ruby

    This is how I started out my day and I think I spent an hour or more doing this. The upgrading part was relevant to my career and tangential to my work today. I suppose there’s no better time to learn about new tech than when I’m working on a personal project. It does slow things down, but it speeds me up when I need to use new tech in my career. I’m okay with that.

    I did, however, get sidetracked with some timing. I spent some time googling for speed comparisons between Ruby 2.0 and 1.9, and then tried creating some command-line benchmarks.

  2. Converting Devise views into Slim

    Devise generates its default views as erb, which I didn’t want in my project. There’s a step for this in their wiki, but it was outdated. I updated the wiki, generated the slim views, then found a bug in the html2slim gem and spent about half an hour reporting it. I took the time to generate a new rails app and repeat my steps so that the bug had clear steps for reproduction. This sort of feels like wasted time, though I think that it’s genuinely useful work for the gem maintainers.

  3. Helping a couple of other people

    This isn’t necessarily a bad thing. I came out to a cafe expecting to collaborate with other people.

    I think I can better limit where I draw my boundaries though. I don’t want to be unhelpful, but I want to work on giving the minimum viable help that a person needs. I think this is an important trait to develop as I become a more senior dev. I felt like I was floundering for technical help at my last company, so I don’t want to put future coworkers in the same position when they want my help.

  4. Comparing two Backbone gems for Rails

    I had a third option–just embed Backbone into the project manually. I wanted to use a gem to ease the future step of generating Backbone scaffolding. I had used the backbone-rails gem in a work project, and I wasn’t entirely happy with all of the choices it made on my behalf. I think this research time was well-spent.

  5. Figuring out how to remove emails from Devise

    This may have been a nice-to-have for making the app simpler for a user, while making things harder for the developer. Devise has built-in support/dependency on a User email. Pulling that out isn’t as simple as removing a config flag. This was a nice-to-have, but could’ve been pushed off until later. Definitely not MVP material (in terms of getting the project done)

In terms of goals I started today with, I failed. I wanted to end the day with an app that would allow you to create two users and allow one to message another.

I can see two decisions I made earlier in the day that might have helped me hit this goal. I considered sticking with ERB and keeping emails as a part of the User model. If I had done both of these, I would’ve saved a couple of hours of research.

Do I want to only focus on getting MVPs out in my pleasure coding time? I certainly want to pleasure code so that I can get better as a dev. Sometimes that necessarily means researching what’s out there to make informed decisions.

At the same time, I also want to develop an MVP-eye to identify the effort involved in producing an MVP. Perhaps I should designate “MVP days” among my pleasure coding, so I can develop this, but not have the emotional drain of feeling unaccomplished or guilty about “wasting time”.