Last week we celebrated our third Hacksgiving at Harvest. This is an opportunity for us to work in small teams on fun projects that interest us, but still benefit Harvest in some way. The only limit is our imagination. A few of us thought it would be fun to make an HTML5 game, and it was a blast! I learned a few things during Hacksgiving that I would like to share.
Keep it Simple
Keep it Simple is one of those obvious things we like to say, but often forget. Initially when I started sketching out ideas, our game was much more complicated. Some ideas that we ended up scrapping early on included: alternating tasks and team budgets, time-based budget increments, and more detailed designs/animations.
When we were figuring out the tech stack we wanted to use, originally the game was going to leverage the Harvest API to use an account’s real project names, as well as tasks and people. Doing so would have drastically slowed us down for a variety of reasons:
- We would’ve had to make sure players of the game had permission to view the projects, tasks and people used in the game.
- Harvest is a rather large and complicated code base. Working inside the app can be slow just because of its sheer size.
- There’s an element of risk committing code to Harvest willy nilly at the speed we were developing.
Keeping things simple not only made development much faster and easier, but also made the game more enjoyable to play. And this is really the heart of Hacksgiving: build something as fast as you can!
Ideas are Cheap! Lengthy Discussions are Expensive!
While building our game, we didn’t spend a lot of time discussing whether a feature was good or bad or how to implement it. It usually took us only 10 minutes of development to figure out if an idea was worth keeping or scrapping. We had only two full work days to make this game, so we couldn’t spend a ton of time discussing things. Having this mindset forced us to constantly churn out work.
When we typically work on a normal project we tend to start with a discussion about it. I think discussion is good, but it can be easy to fall down a rabbit hole of endless discussion. I don’t think lengthy discussion in itself is a bad thing. However, in some cases, I find that lengthy discussions can slow down a project’s momentum.
One thing I like to do to help foster discussions is build quick and dirty prototypes. This gives the team something tangible to play around with so we can get a feel for how the feature will work. More often than not, our prototypes will answer our questions, and help us build better features.
Discussion is a good thing, and so is having a plan. But, when you have that feeling that a discussion has been going on for too long, try getting into some code, and test theories by attempting to execute.
Hanging Out in a Hangout
When you work on a remote team sometimes you miss out on in-person collaboration. It’s a lot easier to ask across the table, “Hey Brad, what do you think of this?” than to ask the question in Slack. You get a real time response complete with emotion and visual cues instead of staring at the screen waiting for Brad to formulate the perfect response only to wait five minutes for a simple, “I don’t like it…” Asking Brad in real time saved me at least five minutes—time I can use to work on something else!
Having a personal connection with the people on the team made it so much more enjoyable to work, and made us more productive.
I always look forward to Hacksgiving. It’s always a great opportunity to try new things and explore ideas—both techwise and socially. I always come away feeling recharged. Now on to the next feature!