What I learned during a hackathon
Recently, $job held a hackathon, though ours spread an entire week so was dubbed "Hack Week". We created some awesome projects, had a lot of fun, and managed to help the company at the same time.
Several projects were very cool{% ref %}though none public, sadly{% endref %}: MapIt, a system to overlay our web analytics on to a map in realtime; Prophet, an algorithm to determine future enrollments in a course given a series of variables; Karma, a system integrating with nearly everything we do to give employees a sense of achievement for doing good things.
A couple of the projects were less "cool"{% ref %}though again, not public{% endref %}: StressDef, a SharePoint based PTO system; HumanaFit Updater, a Dancer application to fetch data from MapMyFitness; DataMaker, an improved QA data generation system.
I worked on two of these projects, and helped out with a couple of the others. I learned in some of my trials that OAuth is harder than it should be. HumanaFit Updater would have been a Slim application, but doing OAuth 1.0 in PHP is really harder than it should be. Same with Ruby; I would have made it a rails app otherwise. Perl made OAuth 1.0 the easiest, so I wrote the app using Dancer.
I also learned that some of my teammates are very protective of their code. I asked a group why a specific thing was happening, and was informed that one of the other developers had written it. I didn't care who wrote it, I just wanted to know why something was happening. Later, when I refactored something to improve the responsiveness of the application, another developer suggested that the code was no longer his.
Lastly, I learned that our collective teams have some very good ideas. Some simpler than others, some rather complex. All very interesting, and beneficial to the company long term.
{% reflist %}{% endreflist %}