Developer experience
The Full Stack Development team spends a significant time writing code. A good developer experience implies a grossly improved developer productivity. Some ways to improve the DX, thereby improving the quality of life and hence the productivity include:
Setting up eslint/tslint/prettier so that the IDE can take care of the mundane tasks like enforcing code formatting, highlighting possible code quality issues, enabling early bug detection.
Integrating eslint/tslint/prettier within CI/CD
Using tools like Storybook with Chromatic enabling UI/UX reviews early on
Basic documentation which will enable an easy onboarding process - viz. Instructions on setting up projects for development on local environment, database structure, API documentation, mock data/API sandboxes.
Depending on the project, if appropriate, adopt a test driven development.
Dependencies & Code maintainability
Choosing dependencies is crucial. Using libraries that are no longer maintained might limit upgrading core frameworks in the near future and might require forking repos to update those libraries and then update the core frameworks. Another issue with obsolete libraries is the security risks. From a productivity perspective, some libraries do not actively host documentation, and new developers find it difficult to use those libraries by referring to code snippets without the documentation. Furthermore, having libraries without type safety make it extremely difficult for new developers to use those libraries without documentation. As such, as far as possible, either long term stable libraries should be used. If only small fractions of libraries are required, possibly create in-house libraries. Long term maintainability with a large number of external dependencies can turn into a maintenance nightmare.
Team culture
Having a positive culture that facilitates open communication, respects individual differences, appreciates contributions, makes people feel valued, has a large impact on how products are built. Code reviews should be what developers look up to, in terms of learning new aspects, instead of dreadful processes.
Design system
For frontends, having a design system, or components that could easily be abstracted to a library can have a large impact on costs in the long term. When a product pivots, or when companies launch new products, the component libraries can be easily be reused across products. As such, having a design system that facilitates themes can greatly reduce the repetitive efforts of styling and maintaining component libraries.
Shipping often
Shipping often and early enables feedback earlyon. In this agile-world, regular shipping enables stakeholder participation, identifies issues early, and makes sure that the developers are aligned with the product goals. If releasing to production isn’t an option, having multiple environments can enable internal stakeholder feedback.
Comments