This is LIVO engineering team operates. We operate in Collaborative Single Player Mode.
Everyone should be able to execute independently without depending on others, but the team should move with the same rhythm.
Every engineer should be able to take a feature from inception to completion without unnecessary dependencies.
- Act First: If a design is missing, mock it up. Designers can refine later.
- Make Decisions: If a product or technical decision is missing, take your best shot. It’s better to ask for forgiveness than wait for permission.
- Hack or Fake: Don’t know how to implement something? Create a placeholder solution or prototype.
While independence is key, collaboration ensures quality and alignment
- Pull in team members for feedback early and often.
- Share progress regularly to keep stakeholders in the loop.
- Follow the team norms
- When blocked -> ask for help immediately
- Everyone is (or willing to learn to be) full stack
- Everyone understands the core domain
- Invest in understanding the business domain.
- Proactively seek input to adapt requirements and priorities based on feedback.
- Don’t fear requirement changes; embrace them as opportunities to better solve user needs.
- Apply the Scout Rule: Leave the code cleaner than you found it.
- You own all the issues after you ship them.
- Don’t implement pixel perfect. Usable, not always flashy and beautiful. Don't wait for design or full requirements
- Question the requirements and ask why and what is the problem we try to solve.
- Start Small: Begin every feature or task with a clear, simple objective—start with one sentence.
- Aim to get something into production every day, even if it’s just feature-flagged to yourself.
- Usable, Not Perfect: Ship functional, usable solutions first. Don’t let perfection block progress. Iterate based on feedback.
- A demo is worth a thousand words, and a working prototype is worth a hundred demos.
- Frequent Releases: Break down work into small, releasable pieces and deploy frequently using feature flags.
Continuously improve tooling and infrastructure to simplify complex tasks and workflows.
- Always ask, “What tools would have made this feature easier?” and advocate for building or acquiring those tools.
- If something can be automated, it should be automated.
- Look for places where reusable utilities or components can be extracted and used later
Don't optimize for speed or quality - optimize codebase for confidence. For the next person to make change and for everyone to be able to reason about it and ask quesions.
- Working code beats abstract discussions and perfect systems.
- Code Practices:
- Namespace and organize your code to keep it manageable and navigable.
- Don’t ask permission to refactor—clean as you go, but be mindful of scope and priorities. Tidy first.
- Remove what doesn't work. Design code as it will be removed tomorrow
- Design code for traceability
- Prefer explicit code vs short code.
- If code style can't be enforced by linter, don't argue about it
- Write tests
All process is up for debate. If you have ideas on how to improve process, product, or code ... 📢
What is expected from team members:
- Respect time commitments. It is okay to miss a deadline, BUT the moment you are stuck, block and realize you can't hit a deadline -> YOU SHARE IT WITH ME/THE TEAM, so we can resolve the situation together. The worst is not hit deadline and announce it the day before the deadline.
- Work with small Pull-Requests. I expect you to open at least 1 Pull Request every one or two days. You should split big features into small releasable features or feature flagged code. Everything shipped should work.
- Have automated tests for your code. You should cover both unit and feature tests.
- Have Loom video walkthroughs of features shared in Pull Requests and in Slack with the team. In this way you can show the feature in action.
- Follow team standards and conventions. If you are not happy with those -> lets talk as a team and see how we can improve them. Every process is up to discussion/revisit, however there have to be good reason for this.