...
If you are doing either the frontend or backend work for a fullstack story, communicate early and frequently with the developer(s) who are working on the other part of the story.
If you have a PR that’s been open for a couple of days with no reviews, notify the team and get it reviewed to help the QA review your work throughout the sprint rather than at the end of the sprint.
If you find you have to do a lot of repetitive work for your ticket (e.g. lots of data entry, setting up a new farm a certain way every time you want to test your code, unclaiming sensors with a third party API every time you want to test your code), create a script to help that process along and share it both in the comments on your PR and , with Mwayanjana Bolokonya, and potentially on sprint-team if it’s likely to see re-use
Currently we do not have a consistent way of handling CSS styling. It’s recommended to stick to one type of styling (scss style sheet, makeStyles, etc) across the application. It’s not feasible to refactor all of the current code, but:
Moving forward stick to one type of CSS styling per component (ideally one throughout the app, but the best approach for styling in this app is up for discussion).
If legacy styles for a component are working as expected, leave them as they are.
Otherwise, refactor them such that all styles for the component are in one place.
Avoid in-line CSS styles.
There are many limitations to in-line styles (ex. you can’t access the hover state of an element)
It can cause specificity issues if you want to override those styles later on.
It makes it hard to find all the styles for a particular component.
...