Kindness Driven Development Over the last one and half years in Techwondoe, we have worked on 20+ Products with a 50+ member team completely remote. It has become clear over and over again that all things could be better if we just are kind to one another in the activities we do. Sometimes we don’t know what they are and how positively they can affect the colleagues we are working with or the product we are working on. So, we have decided to document the kindness practices that help in product development and help everyone get a happy and healthy environment to work in. We call this Kindness driven development:
Pull requestors and reviewers Please do pull requests for all code that gets merged to the main branch. Be kind to the product and maintainers of the future. As a PR requestor, be kind to the reviewer by:
- linking PR to a task in Jira so that reviewer has the context of what they are reviewing
- adding screenshots or better a video gif of the working functionality so that it is clearer to reviewers and even prevents them from having to run your code.
- not introducing unrelated changes. That confuses the requestor. Eg. don’t do linting fixes etc with a PR for another change. Do that in another PR.
- adding descriptive comments of your thought process about why you made certain decisions or better call up the reviewer and explain to them and give them a quick walkthrough.
- appreciate comments from reviewers. They are being kind in spending time in an activity that is not every developers first choice. They are helping make your code and application stronger.
As a PR reviewer, be kind to the requestor by:
- checking the functionality is met via the PR. Run the application and check it looks good.
- ensuring there is no tech debt being added to help everyone in the future.- ensuring code follows quality checks
- automated and manual checks
- not being negative in comments. Help improve code and people’s knowledge. Don’t show superiority
- taking time to review and make a difference in quality.
Team Leads and team members As a team leader, be kind to your team members by:
- listening, not just speaking. Be open to feedback. Empower.
- keeping them informed about the direction of upcoming work
- not committing to unrealistic deadlines- setting clear expectations. Having written expectations helps.
- including devs and testers in design and providing design walkthroughs.
- catching up regularly with individuals and helping them if they have any issues. Be kind.
As a team member, be kind to your team lead by:
- providing an end of day update, especially if you are in different time zones.
- keeping communication verbose. Remote work has flexibility but needs more comms to be effective- asking for help if you are stuck
- updating the team on slack about your status if you can’t make a meeting.
- updating team members if you are going to be away for a few days. The longer you are going to be away, the longer notice you should give your team.
- keeping status and comments updated in stories.
Developers and Testers As a tester, be kind to the developer by:
- test planning with devs even before development so all are on the same page.
- finding issues in software, not in people. Let their mom or spouse make them a better person :)
- understanding the goal is to ship a great product and the resolution of any flaws. The count of bugs does not matter
- providing clear instructions on how to reproduce any issues. Provide a video of the issue happening or a login where the issue is occurring. Have a call with the dev.
- providing clear expectations with regards to what is expected to happen versus what is currently happening.
As a developer, be kind to the tester by:
- taking bugs positively. Testers are the final defence before the code goes to battle. Respect that. Don’t discard issues as trivial or non-issues.
- understanding minor UI issues are major for the client. You wouldn’t like apple products as much if their apps were not pixel perfect. try building products with the same quality. That is what testers are trying to ensure.
- participating in test planning before development, so you develop it right at the first attempt.
General Tips
- Nohello.com, really important for remote communication.
- Be before in meetings by a minute. Especially, if there are many people in the meeting.
- Accept or decline meeting invites so colleagues know if you would be joining or not.
Key Takeaways
The essentials, distilled.
