Welcome to GeekHunter docs! Grab your cup of coffee (or tea) and read this with attention. ☕🍵
Here we document our workflows, styleguides and patterns.
- No code is better than no code (if I didn't know how to program, how would I solve it?);
- Delivered is when we can prove that the customer received value in production;
- Customer used;
- We collect usage behavior, we prove it works;
- We monitor bugs and performance issues to make sure it's done right;
- TDD is an implicit requirement of any code intervention;
- The sprint is always the guide, tasks outside of it should be the exception (“Top! Tell our PM to prioritize for us!”)
- Refactoring code is important, but the focus always needs to be on the task
- Fixing code outside of it can generate value but can compromise your schedule related to what you expected to deliver initially.
- Start double, deliver solo: always open tasks in pair, building the test scenario until the problem is clear to be played in solo mode.
- This way we can ensure that we're actually solving the problems meant to be solved in the task, while also validating if the task itself makes sense.
- When the brain gives Timeout, raise HelpException;