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 permission or forgiveness, handle the outcomes.
- 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 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.