5 Learnings from the #wirvsvirushack from a developer perspective
Germany organised the hackathon #wirvsvirushack on 20th March. About 42 thousand people from all over Germany took part in the hackathon to help in the corona crisis with new digital ideas. The goal was to create a prototype or an application that can help in the crisis.
But this article is not about the solution our team developed, but how and what my learnings are. The idea of the article is to give you these learnings so that you too can possibly work together more productively in everyday environment.
Our team consisted of 2 designers and 2 developers. So we had more or less a 1:1 support. Furthermore, there was no product manager or someone who made requirements except us.
1. five hours of coding saves one hour of planning
At the beginning we thought about the idea for a long time and worked it out. When we had a rough concept, me and the other developer started to code. We quickly created a first prototype, but it just didn’t match the design. We had more work to do to adapt our code to the design afterwards than if we had just waited and helped with the design. It would have been much more helpful to help the designers and to code as soon as the first screens were ready.
2. Close cooperation with the designers helps
That part coincides relatively well with 1., but not only that, it’s also really amazing how you get spurred on when you see how the design is progressing. I was super motivated to follow the design and build it in the app as soon as possible. I’ve seen all the other work and I’ve been very motivated to work on it and as soon as a new design was ready. But that requires a close contact to the designers. Since we’re all in quarantine right now, we were in a meeting all the time. (longest meeting was 10 hours the one day :-D)
3. Meetings can be useful when few people attend
I experience meetings every day. Not every meeting makes sense. In some of them there are so many people that you don’t say anything anyway and the information that is said doesn’t always affect everyone, of course. As a result, you often walk out of a meeting with the feeling that you could have done something else more productive in that time. Fortunately, in my current job, this is not as bad as it used to be, but it happens sometimes too.
There were only four of us at the hackathon and so in the meetings. But not only meetings to discuss something, also in meetings where everybody was working and only talks about the progress. So you always have the feeling that everybody is doing something and it’s going ahead. Also, the chance that the topics get lost is very small with so few people and you are very focused.
What I took away from this was that after the Corona crisis, maybe some kind of project-sitting groups would be useful. That way, everyone who works on a project is also together. So the topic is often focused on the project and you have constant progress, because you can see how things are progressing.
4. New technologies can help
Yes, this is the most difficult and controversial issue. For me, anyway. I code some languages quite well, others hardly at all. And I can understand when people then say that I’m going to bet on the old languages that they know well. For the hackathon we took up a challenge and used a language that we both could hardly or not at all know. Because in the end it was about learning something.
And I was positively surprised how fast we could achieve so much. The beginnings were a bit bumpy, but when we roughly knew how to do something, it went really fast and clean. Sure, we encountered problems that we couldn’t solve at this short time.
But new technologies are usually designed to be faster and better in development and make it easier. Because nobody would say, “Yeah sure, let’s use a language that makes everything harder”.
But all in all, it has proven itself for me and in the future I will continue to try out the latest technologies and when it comes to what, I will always rely on those with which I had the best experience when prototyping.
5. Pairprogramming!!!
Last but not least, pairprogramming. Yes, even pariprogramming can be done remotely. We just shared the screen, one of us programmed and the other one watches and comments. This way we were able to solve problems that would have taken much longer to solve with a simple discussion. I think pairprogramming is very helpful and should be mandatory for a few hours a week.
It is not helpful in all areas. If you just have to write code down because you want to follow the design, then no second developer has to sit next to you and watch. But honestly, that’s not the case most of the time in coding. Rather less.
