Attending a Hackathon when you cannot hack, how bad could it be?
On the 22nd April I took part in a Cloudreach Hackathon called .create() (for more details read the blog about it here). So what is .create()? It is basically a 48 hour hackathon where teams of up to 3 people work to try and create something new. Each hackathon has specific rules; usually about using a new piece of cloud technology released in the last 6 months. Hackathons aim to improve and up-skill people whilst focusing on innovation and other skill-sets sometimes not harnessed in your day to day work lives. I plan to write more specifically about what my team did in a future blog, but here I wanted to focus on the personal development (one of Cloudreach’s core values) I had from this experience and the learnings I had from this sort of event. I hope that these learnings can be taken forward into formal development practices within Cloudreach and also amongst my connections’ organisations. I think we could all embrace the hacker within and I advocate for a bit more disruptive innovation in our day jobs.
To be honest doing a hackathon was nerve-wracking for me
To start with I was nervous about how effective I would be as a team member as I have not come from a technical background, but a business background where I have learnt technology throughout my career. I let these nerves get the best of me and missed the first .create() event. However, this time I ignored them. What was the worst that could happen? I thought: I am AWS Solutions Architect certified, I have been working with Azure recently, and I am confident I can cover off the IaaS and PaaS elements. It was the Infrastructure as Code elements that worried me. I had previously managed and worked on projects and programmes that delivered this but I had never written the code to make it work. Not to mention, I really only had hands-on HTML and Java knowledge from when I built my own website prior to Cloudreach and some training on python using (Codecademy) whilst at Cloudreach.
How’d it go?
Well after getting past the initial nerves, I really enjoyed the experience and the end result was a real success that taught me a lot. We ended up delivering our working PoC (proof of concept) app on time, with full documentation, demo videos and even had some fun creating internal social media posts on G+ and videos for our colleagues to watch during our hackathon. For me personally, I learnt a lot that I want to share with you. My key takeaways are summarised below.
Effective Teams need different skill sets
I learnt that effective teams need multiple skills sets and that my areas of weakness were strengths for my other team members, and vice versa. This resulted in my team having a more balanced skill set than other 100% dev focused teams. My other two team members were talented Cloud System Developers at Cloudreach and were not concerned about my skills in those areas. What they needed help with was documentation (another learning below), planning, staying on track, architecting the solution, idea creation, troubleshooting bugs, testing the solution and dashboard visualisation. I was able to help with all of the above which kept me super busy over the 48 hour period.
Everyone has to learn somewhere
No one is an expert at everything and during this hackathon, google and time were my friend. Whenever I hit a problem I googled the error and solution and spent time trying to solve it. This allowed me to get hands on experience with AWS lambda, AWS S3’s new console, to play around with Spot pricing as well as more log based troubleshooting using CloudWatch, X Ray and other tools in AWS. Ultimately a lot of these specific situations and issues were new to my teammates even though they were more experienced, and in reality we all started from a relatively similar position.
Working on documentation live in parallel with the developer releases value immediately
As I touched upon above, one thing I found really effective in working in a small team was documenting throughout delivery. Whilst my other team members coded, I chatted to them about what they are building and documented it live so we always had something we could submit. This was really an agile method of delivery as it meant development documentation testing etc. were all done together within the team.
Although I probably didn’t use 20% of what I wrote, as the code or the solution changed midway through, it was not wasted. The time saved by working in parallel and closely together outweighed the waste and resulted in an overall gain to us as a team. Another benefit of this method is that if we had needed to stop working for some unknown reason midway through, we would have still had something that was understandable and able to be worked on by another team in the future.
I can architect and build a working solution
This was more a personal observation, I got the opportunity to architect a solution which I haven’t been able to do during my career. Over the weekend, I wrote the technical documentation, drew and published the high level architecture and the best bit is, it worked! That was a fantastic feeling.
Small teams with passion and tight timelines can deliver a lot
I was really pleased with what our team of 3 people in the span of 48 hours managed to achieve: From “Idea” to “Live Working” prototype in a weekend felt amazing. It has further driven my passion to be more innovative as the cost is very small. It’s really only taken 6 days total effort from idea to working product which is a crazy level of speed.
If the work is fun it doesn’t seem like work
Although this hackathon was over the weekend, after an already long week at work it really was a lot of fun and the 48 hours flew by. This has reaffirmed to me personally that if work is fun, it’s not really work at all.
Agile tools are great but working together in the same room with a whiteboard is all you need
Last but not least, we worked on Friday night and Saturday in the same location and remote on the Sunday. Although on the Sunday new cloud based tools for communication like instant messengers, live chat websites and Trello for task management were very useful to collaborate when we were remote, they didn’t really beat sitting together and simply using a whiteboard and pens.
In summary, the .create() hackathon was a real treat and if you ever have a similar chance to participate in something like this I strongly recommend you giving it a go and not letting your nerves get the best of you. I really hope you take away the learnings I have shared and get some benefit from this blog post and can apply something from this to your next project.