Hackathons can be an excellent learning opportunity but it can be pretty daunting joining one as a tester, especially if you have no or limited code experience.
How do you think testers can contribute during hackathons?
1 Like
This might wind up being a story…
Once upon a time, as all stories begin, I had worked for a company who thought that a hackathon was a good idea. Not only that, but everyone in the team were required to participate. This included the support, sales, and management.
The eventual “winner” of the hackathon was (rightly) a team with a cross section of people. That is, a marketing expert, a technical manager (With no programming experience, but a lot of domain knowledge), and one of our team’s top front end programmers.
In other words, they fit nicely into a 3 amigos setting (different distribution) where the marketing person could help with the presentation, the technical manager would toss out ideas and help plan the implementation, and the programmer would go out of his comfort zone and program a back end. Nobody was bored, and the product and presentation were outstanding for two days work (it was a 2 work-day hackathon, with presentations on the third day)
So that’s one idea, you could figure out the non-programming roles where you can help with and do those. Teams LOVE it if you take care of making the presentation / demo while they are busy with other things.
Now our team went with a different approach. Two testers, one with programming knowledge (me) and the other with domain knowledge teamed with a system architect and we promptly decided to use the hackathon to create a test tool that would lose the hackathon, but we would use it in our testing efforts once the hackathon was done.
To make life difficult, we decided to use javascript, which I had never touched before and the architect had only dabbled. So on top of a new (ish) product, we learned enough about a new programming language in two days to implement it. We were able to split up the software work enough so that the tester could make sure it worked in the two days we were given. So while we were not the flashiest of teams, we had probably the highest quality (we were the only team to not suffer from the demo-effect) and we actually used it in our work after the hackathon.
In both cases, the secret to finding things to do in a hackathon is to talk with the team. Most reasonable people can find a role for you that you will, if not enjoy, at least feel comfortable in.
6 Likes
I’ve not been to any myself. But I’d want to contribute and be useful. Well said @brian_seg
1 Like
My experience of this also, go cross-functional. I used to be very anti-hackathon, because my company had entire teams of testers, most of whom were not coders, and even so could not add product value. Eventually we got used to the idea of using the hackathon to either learn a new language or platform like groovy-scripting for Jenkins pipelines or to build that cool reporting tool you never had time for before. Trying to win the shiny hackathon prize, is not always worth as much, as a week to build a new tool or skill that your team lacks.
2 Likes
I suppose that brings up the part-2 of this hackathon not-trying-to-win experiment. That was my first experience with javascript. Now I use js nearly every day.
2 Likes
Our team has one or two week-long hackathons a year. I like to pick small scripting projects that serve as proof-of-concepts for a more skilled programmer to implement correctly later, if the team thinks it would be helpful. Our QA members that don’t code are always very well engaged, as well. Some examples of how they participate include: teaming up with a developer, trying out a new tool that may help us with a problem, or demonstrating an interesting application of our own product. While I suppose some of these examples may not be strictly part of a “hackathon”, no one has ever minded and it allows everyone to contribute and learn something new.
2 Likes
We have things called firebreaks that involve doing something you don’t normally do like innovation idea for the product, explore a new tool or do some training. Lots of ways to get involved that are not coding.
1 Like
The company I’m with has tech days a few times a year, where it’s 2 to 3 days to work on a project that’s not directly work related. Sometimes people scratch an itch that’s been bothering them, but other times it’s just random hacking.
Lots of non-coding projects, including things like how to make our interview process better, how to improve documentation (both internal wiki as well as client facing docs), ideas for how to improve our coffee situations (i.e. how can we stop having an empty pot so often). There’s also been plenty of more DevOps oriented projects that might be easier for those with non-developer skills - improving our container registry, experimenting with GCP services, etc.
2 Likes
To be honest, I have been into multiple hackathons, I have contributed to code many times and won.
You can do it.
You just have to know what you have to do, You can figure out the how part.
1 Like