Software engineering at Restack
/ 4 min read
What we believe in
User-centrism
The goal of a Software Engineer at Restack is to bring value to the user. Thus, we are responsible for the whole cycle - from understanding the needs and discovering solutions, through execution, delivery and success validation.
Understanding the business
In order to propose a solution, it is important to understand the business context - what stage are we at, do our decisions correlate with our mission, and what is the priority short and long term.
Self-care
Development environment should be a pleasure, not a struggle. This includes constant improving of our tooling, processes, and codebase quality.
Software engineering is a team endeavor
Humility, Respect, and Trust are our core values when working with each other.
What we value
- Embrace curiosity
- Proactive collaboration
- End-to-end ownership
- Clear communication
Excellence at Restack
🚦 Quality
Every engineer is responsible for the quality of the work and the product. It is a goal for the team to report and address problems during the PR review. Bugs can be filed by anyone and should be given Steps to Reproduce, Current and Expected outcomes.
🚢 Releases
We believe in Continuous Deployment - every time code is merged to main, it is deployed. Developers should know & understand how the code is reaching production. It should be a pleasure to deploy code. We use every opportunity to ship and avoid large releases.
🛠 Tech excellence
Tech debt is managed by the teams and should be continuously addressed. But not only - we take time to work on faster deployments, better observability, and higher test coverage.
🗒 Pull Requests
All changes to production should be visible to 2 pairs of eyes. For sized changes - draft PRs to indicate the idea and collect early feedback. We aim for quick reviews and avoid long-living PRs.
🔎 Observability
Understanding our projects’ state and being informed about our issues is important before our users start experiencing them. Every error in Sentry should be investigated right away.
👩💻 Collaboration
We use Pair programming on a weekly basis - it helps us to onboard new engineers, enable easier reviews and close the knowledge gap.
🏎 Performance
Make it work, make it right, make it fast. Thus, performance optimizations are done after thoughtful research or user feedback. We use numbers and benchmarks when talking about performance.
🥪 Compactness
We aim for simple & reusable solutions. Projects and teams should use the same tooling, libraries, and techniques so we can share our knowledge and jump between projects. We do not introduce new processes, languages, or tooling if we cannot support them.
✅ Definition of Done
We call a task done when it serves our users.
📖 Education budget
Every employee at Restack has an unlimited education budget for books, courses, and tooling.
How we work as a team
Agile at Restack
In the roadmap, Stories are collected to be done next. They should be not smaller than 2 weeks of effort (otherwise, Stories are merged) and not larger than 6 weeks (otherwise splitted). Every Story should have an owner**.** We should optimize for fewer stories In Progress.
- Stories:
- Refinement: Async before the work starts. Understand the Story from the Roadmap, and define functional and non-functional requirements together with Story owner.
- During refinement, we aim to understand what problem should be solved (Motivation), define when developers know that they are done (Acceptance Criteria), think of potential solutions (Tips), and answer Open Questions.
- Kick-off: Moment when everyone in the team is ready to start working on Story. Discuss deadlines, availability, concerns, and way to release.
- Execution and Release: Users can benefit from the effort and avoid large releases.
- Celebration: After a successful release, celebrate the hard work.
- Demo: For every Story done, results should be shared by the team
- Retrospective: Discuss what went north / south. Should happen right after release to collect fresh feedback.
- Cooldown: for 1-2 weeks, work on Tech Excellence, bugfixes or have a Hackathon
- Success measurement: After 1 week, evaluate if the feature was successful
Flexibility
Other activities, like dailies, are in the format and time upon team agreement.
Kanban board
The process must serve a purpose. We aim for getting work shipped, rather than tickets moved in the board.
Board helps us
- Understand what we are working on today (In Progress)
- Inform that task was done (Completed)
- Pick up next task (Next)
In practice, we should aim for a single ticket In Progress. One single bugfix shipped is better than 2 tasks in development. Every ticket should have only one Assignee. Assignees are responsible for keeping tickets in the correct state.
Resources
https://www.atlassian.com/agile
https://about.gitlab.com/handbook/product/ux/jobs-to-be-done/
https://www.amazon.de/Software-Engineering-Google-Lessons-Programming/dp/1492082791
https://www.mountaingoatsoftware.com/