What is a ‘hackday’ and why have one?
Working on a new project is enjoyable and liberating; now multiply that 10-fold with an opportunity to quickly prototype software as a team over an intense 24-hour period and you have a ‘hackday’ – something which is even more satisfying. Hackdays are a superb way to give the team freedom to work in a way they want whilst exploring innovative ways of improving the product suite. On top of that, it’s also a great way for staff to show their talent and creativity in ways they may not ordinarily get the opportunity to.
What did the Science Warehouse hackday look like?
The day started with a kick-off meeting where the plan for the day was presented to all those taking part. There was a time limit of 24 hours and a list of challenges defined by the product management team.
Support analysts, QA engineers and software engineers took part. The support analysts formed pairs, as did the QA engineers. We currently have two development teams and the software engineers had pairs chosen for them made up of a member from each of those teams. This helped foster knowledge sharing over product domains.
Each pair was given a challenge, pizza was provided and the hackday began! With no requirement to use the existing technology stack, we had free reign to use whatever (non-commercial) tools/languages would help produce the best solution – this included Elasticsearch, DynamoDB and Scala – to name a few.
24 hours was a deadline – not an invitation to pull an all-nighter – so most of the work was completed within the usual office hours with a few extra hours from home. After the 24 hours were up, we presented our solutions to the rest of the teams and voted on a winner.
It turns out calling yourselves ‘Team Win’ doesn’t guarantee coming first place… That honour went to our QA engineers Tom and Andy who implemented a proof of concept for using Selenium Grid within the current automation test framework. Aimon and Alaric came runners up; they harnessed an Elasticsearch-backed index to perform ranged queries on catalogue pack size values and prices.
Tips for best results in a hackday
- Work with what you know – The opportunity to work with new technology can be refreshing but be realistic. Choosing a language on the day you have never coded in before means you aren’t going to be productive.
- Sharing is caring – Just like pair programming there are many benefits to working closely in a team e.g. mentoring and knowledge sharing in application domain, technical and design areas. Ensure teams are as mixed as possible with senior and junior staff working together.
- Set realistic expectations – Plan before you start coding and have a minimum viable product in mind. If that turns out to be easier than expected then you will still have time to add all the bells and whistles you want… Start with the bells and whistles and you’ll probably end the day with nothing to present.
- Have fun – True, it is a competition but it’s also a chance to learn something new and experiment. Don’t worry about not achieving as much as you set out to – just try your best.
Preparation is key – learning what the challenges would be on the day meant time had to be spent preparing the environments on our machines when we would rather have been working on the solutions. No doubt, next time round, teams will be given notice in advance so that no time is lost on developing solutions.
All things considered, the hackday was a great event that all participants considered a success. It was impressive how much was created in such a short time. For me, the hackday was a fantastic learning tool and team building exercise that I can’t recommend enough; with the added bonus that at the end of the day we had a collection of fresh ideas and approaches to build on in the future. I look forward to the next one!