Тhoughts after the Summer HackFMI

Last week we pulled off a HackFMI event during the summer break in the university.
The Summer hackathon was with a different format than the standard HackFMI – 5 days long, everyone is on the same team and we have a clear goal for what we have to do.

And since you can read this article, to get a sense of the entire hackathon, I will skip the summary and go straight to some observations and thoughts about the format and the work we have done.


That’s the name of the system we were working on, during the hackathon.
It means “transparent” in latin and its purpose is to serve as a public archive of the Student Council’s work in the university.

The set of the hackathon was the following:

  • 10 people writing code in 2 different teams – backend (Python and Django), and frontend (HTML and JavaScript).
  • A full document with specifications about the system.
  • Two project managers, reading the specifications and handling a Trello board
  • Github as a main repo and source control system

I will go through each part from the work on the project and share some insights 🙂

The setup of the project

Making Python / Django and PostgreSQL work on Windows is not a trivial thing.

We started off by creating a README.md file in the repo, that explains how to set up your environment and run the project, which saved us tons of time.

Of course, running a Postgre on Windows is mission impossible, so Hristo (Part of the backend team) added an example of local_settings.py for SQLLite, which ended up running without problems.

An up to date document with the project setup is essential for moving fast, especially during a time-limited hackathon.
We had the following scenario – new people coming and asking how to set up the environment. The answer was easy – follow the instructions and if they fail, search for Hristo or Kiril, make it run and update the setup document.

I think we managed to get up and running with the setup quick enough to start coding during the first day.

And of course, no one with Linux had any setup problems.

Takeaways (TL;DR version)

  • Keep a file (README.md is a good choice) to describe how to set up and run the project. It saves a lot of time, when new people are joining in.
  • Always keep that file up to date 😉
  • If someone struggles with setting things up – it’s a good idea to help him as soon as possible or else, he will slow down the process in time. Something like fixing bottlenecks in Kanban.

Git add what ?

Git turned out to be an irreplaceable tool for the project.
We started working on two separate branches – one for backend and one for frontend and we did not follow any specific github flow / git flow / skanev flow to work with.

Most of the people were familiar with how git works, but the way to learn git is to work on a real project like that.
The moment people started pushing into branches, which had more recent commits than their locals, things started to get interesting.
And of course, merging and rebasing backend and frontend branches into master, and into each other produced a good amount of conflicts, which turned out to be a good thing, because people stopped being afraid of merge conflicts. <<<<<<< HEAD is not scary 🙂

It turned out a good idea, to write on sheets of papers the git commands you need to run in different situations, like pulling before you push, or fixing your commit message after you have committed.

Also, Git UI tools were not that effective in merge / rebase scenarios. You need the power of shell.

It will be great, for every freshman, studying Computer Science in the Faculty, to take a Git crash-course.
People that do not know Git, are afraid to commit and afraid to write code on their own, which slows down the entire process.

In the end, I think, picking a flow (Git, Github, Skanev) to use with Git/Github is a better idea than just chaotic commits and merges. The problem is that those flows make no good, when people don’t know Git well.

Takeaways (TL;DR version)

  • Make sure everyone understands how Git works. Have a Git guru in the team.
  • Don’t let people use Git UI tools. Eventually they will end up doing something with Git shell and if they use UI tools, they will have no idea what to do. Start and stick with the shell.
  • Pick a flow to work with. GitHub flow seems like the best choice if you want to move fast.

Team work and delegation

I played the role of tech team lead for the frontend during the hackathon (For which I don’t have much experience).
It turned out, it was not as easy as it sounds – people seek out your help and you should be prepared to think fast and execute fast in order to move fast (Again, we had only 5 days to ship something working).

The hardest thing for me was to break focus, when coding some feature, in order to help a struggling team member and after that, regain focus again.
The thing that worked was to break down the frontend tasks and delegate them to the rest of the team members. People lose motivation when there’s nothing to do, rather than having a lot of work on them.
And when someone struggles with a task – show them how can be done and let them finish it after. And of course, after a feature is committed – do a code review and refactoring, in order to keep everything clean.

Takeaways (TL;DR version)

It was new experience for me, so I can’t summarize any good TL;DR version for this one 😉

Kanban board and Specification

During the hachathon, we had a Trello board with standard setup (Backlog, Doing, For Testing, Done) and the specification broken down into cards, split in four different categories – frontend, backend, top priority and low priority.

This helped us a lot in the beginning to take off with the project.
The only thing is, that whenever I work with Trello (Or other Kanban-like tools), I see one big flaw – The board does not update itself automatically 😀

We had to constantly keep up to date with the board and Trello does not have a good way to signal if there’s a change in the card description (Which happened a lot – people working on a card, when suddenly, some of the specification changed, the card was updated but with no proper notification)

I imagine the perfect situation, where Trello checks Github and has some suggestions, according to the commits when there’s progress in a card.

About the specifications – everything unclear was resolved quickly, during the hachathon, thanks to the project managers and Daniel Stoev (The head of the Student Council and the guy who inspired the entire event) who was present there all the time.
There’s nothing better to actually ask your client whether the thing you are building, matches the specifications in his head. This saved us a lot of time and rework.

Takeaways (TL;DR version)

  • It’s a good idea to have a guy / project manager whose only job is to keep Trello up to date. This reduces the chaos during the project.
  • When a task is done, put the according commits in the Trello card, because it makes it easier to track and check for bugs.
  • If you can – have your client / clients / some of your target group with you for some of the time during the development. Make something people really want 😉

IRC is a good idea

And one final thing – we kept the chat communication in IRC. IRC is a good choice, because if you pick the channel, there’s no random noise and distractions from outside. Plus, it brings more “hacky” atmosphere to the event 😉

We used hitchcock.freenode.net as a server with #HackFMI as a channel.

Write us your thoughts about this post. Be kind & Play nice.

Leave a reply.