My engineering principles
I created this by thinking about concrete things and trying to generalize them, but I don’t want principles that are too general. Did I succeed? I’m not sure.
Could someone disagree with these principles? I think then I’d know that I’m expressing something specific to me and not just a universal platitude. Time will tell, and this may evolve.
Maybe it is helpful to gather these together and make them explicit, even if they are universally unobjectionable.
Some of this is aspirational. I like to think of myself as a person who values these principles. In reality, I may not live up to them.
This should develop into a Topic article at some day.
These guiding engineering principles are numbered for easy reference. The order is incidental and not indicative of priority.
- Engineers should make something useful. I love making use of research, but I am not a researcher. Actual real-world use cases should drive decisions as much as possible.
- Engineers should hold ourselves to high standards. I am collaborative and make well reasoned, well documented decisions considering alternatives and trade-offs.
- Formality should be commensurate to the desired degree of robustness and reliability. Accessibility requires grace and informality. Strictness and formality are necessary in degree.
- Simple things should be easy and complex things should be possible, if ugly. Defaults should direct you towards simplicity. Complex things should stand out shamefully.
- Elegance and usefulness should not be mutually exclusive. I am making something that is beautiful and joyful in its usefulness.
- The core should be stable and slow to change. I prefer affordances for organized, controlled user extension rather than frequently modifying the core. If something makes it into the core, ideally it has proven itself first as an extension.
- Changes should be non-breaking. Accept more lenient inputs. Choose defaults for new inputs. Produce stricter outputs. Choose new names for new functionality (namespaces are helpful here).
- Things should self-describe and require as little context as possible. The more you can understand directly and locally the easier it is to use, understand, and extend.
Discuss on: