Engineering Principles
Here's collection of principles that we use to guide how we do engineering here at plaits community. This is a living document, so if you have any suggestions for a new principle or changes to existing ones, please do so!
1. Community and Design Principles apply
As an engineer your main role within the plaits community is to demistify the technical, as expressed in the Community Principles. Remember we're all in the same community, we all want what's best for each other.
Whenever you contribute code or provide feedback to the designers or product folks, keep in mind the Product Design Principles.
This also sometimes means that you will have to be the person who says no - especially if the proposed feature would introduce a lot of complexity to the codebase.
2. Don't be afraid to look stupid, embrace it
We're all here to grow and learn together. This can only happen if you allow yourself to be vulnerable. Don't be afraid to admit something is too complicated or confusing, because very often you might be facing complexity. If it's accidental complexity it might get simplified; if it's essential, it should be better documented.
This also means do ask. We're all wired to help others, and this can only happen if others do ask for help. Please do ask humans over chatbots; teaching others is the best way to learn by far, but it also helps build the community.
Of course, in order to enable that, you must not treat any question as stupid. Try to help when you can. See if the question comes from potentially accidental complexity, and if you can simplify the code.
3. Strive for simplicity
Avoid complexity at all costs. Do not confuse simple with easy; simple is usually quite hard. Do not compromise on this principle for the sake of time.
Ask others for suggestions or second opinions. Sometimes even a discussion about the feature can help simplify the code or make it easier to comprehend.
4. Pay attention
We're working on software that, unlike most of the software out there, can be matter of life and death. This means you need to be focused while contributing code, and pay attention reviewing code.
Mistakes and accidents do happen, but what matters is how we recover from them.
PS. No gen-AI please
This is not really a principle, but given where the software industry (which we strive to not be a part of) is, it bears repeating the ground rule from the Contribution Guide.
Do not use LLMs in any way shape or form while contributing to plaits. We had fun writing code before this crap appeared, let's keep having fun.