So, we did a hackathon at work this past week, specifically geared towards front-end engineering. It. was. awesome. For one thing, we got lots of free beer from the people over at Hops and Grain Brewery, their Zoe beer was pretty tasty, and kept me riding the Ballmer Peak for the better part of 2 days.

The intent was to give us all some uninterrupted time to focus on battle-testing ideas or general innovation within the company using a variety of available front-end technologies. We split up into groups, chose our names, chose our topics, and went to work. The company sponsored our meals, and our respective managers (as well as those that sit on high from up above) signed off on the loss of 2 days of productivity for their respective products in the hopes that we could gain something for the company as a whole.

The projects covered a variety of topics, all of which actually seemed to gel together really nicely. We had one team working on setting up a Testswarm server with Jenkins integration for unit and continuous integration testing as part of a product’s build process, even researching the potential for outsourcing of some of the test configurations to BrowserStack. Another team looked into setting up an internal Bower repository for the hosting of our various front-end modules, and then wrapping it in another service layer that they could use to also search our internal Node.js module repository. This way, we could tie the ease of search of those of those things into 1 service for obtaining javascript modules for our products. A third team focused on mobile-first design using Sails.js and a simple demo app for something like we might deploy. The fourth team worked on data visualizations with D3, and how we might integrate something like that into one of our current products as a proof of concept for drilling down into some of the data we offer our customers. The fifth team also worked on data visualization, but in the context of code complexity using Plato. Then, there was my team, team Widgety Wack, and we focused on a newly-proposed method of breaking our widgets down into their base components, making those as robust as they could be, and then reassembling them into more complex components, to be able to show that in doing so, we would offer a lot more variety for complex components, as well as the advantage of keeping them reasonably unaware of anything else they’re interacting with on the page, using a mediator pattern at higher levels to handle interactions between all of the disparate pieces.

My team didn’t win, but I certainly don’t consider what any of us accomplished in those 2 days to be a loss. Management seemed to be happy enough with the results that we may be able to do other hackathons on a semi-regular basis, every 4 months or so. I got some actual testing done of some of my own theories for how to rearchitect our internal Platform widget library, and we got a lot of groundwork laid on some now partially finished projects that will help us better organize and test our code going forward.

Anybody that’s never participated in anything similar, I would highly recommend doing so. If you can’t find an opportunity to participate in one anywhere, try recommending it to your own bosses, wherever you happen to work. You never know when you might get a receptive ear, and the loss of immediate productivity from allocating company resources to something like this can be far outweighed by the longer-term benefits of some of the things that can come out of a well-executed hackathon. It also gives a good opportunity for employees across product teams to be able to come together and work for a change, which can lead to brainstorming and idea generation that might not otherwise ever be conceived.