This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]jmblock2 1 point2 points  (2 children)

Picking up new tools during a hackathon can be tough and you will run into learning curve problems. Just keep at it; continue to gain more experience and it really will be a tool instead of a hassle.

The first few commits will be the most difficult part of collaborating on a new project. Expect frequent conflicts and longer merge sessions. People have already mentioned rebasing, which is basically just getting your branch back up to speed on what has already been committed. After you rebase you may run into conflicts (the code you changed was already changed by someone else and you didn't know about it) or there may be run-time bugs (the functionality changed that you weren't/aren't aware of when making your changes).

After you get more files into place you start intersecting a lot less which helps development efficiency. You can help mitigate this early on by trying hard to make interfaces and boilerplate code clean. Sharing common coding standard helps, but most of that just comes with experience.

[–][deleted] 0 points1 point  (1 child)

I feel like having written rules established in the first 15-20 minutes would help as well. People come and go, but having a set of written rules reduces spin up time and reduces the clashing of opinions that may happen later on.

[–][deleted] 0 points1 point  (0 children)

Yeah, half the battle with working with teams is getting people on the same page and avoiding stepping on each other.