What I’ve recently learned and from what.
I think an org could default to non-blocking and still be easily machine readable. “praise:” also seems a little goofy. Otherwise I love this concept.
- Suggestion: Make intentions known when commenting, by using Labels:. This has a side effect of clarifying tone and limiting misinterpretation.
- Issue: one could interpret you, your as accusatory. This is poison in community projects.
- Suggestion: use we, this where appropriate to create distance between the author and the issues.
Progressively add features while focusing on content and accessibility.
- Go is fast. Our code doesn’t need to be; at least, not at the expense of simplicity.
- Write with minimal configuration, minimal exposed APIs.
- don’t be afraid to repeat code, better than rigidly DRYing which adds complexity
- Don’t use more than one tag per structure field.
- Seperate API / Storage models (API responses don’t need to be an entire user struct)
- Writing the boilerplate takes less time and effort than debugging mapping edge cases
- The important part isn’t the directory structure but how packages and structures reference each other.
Software: Strong emphasis on planning, with events in the User / Data flow. Organize a cause and effect using sticky notes, each constituting an event in the flow. This answers:
- What problems are being solved? (user)
- How are these problems being solved? (engineering)
- What unforeseen issues may arise from the flow? (engineering)
- What steps are critical, what steps are unnecessary? (user)
Iron out complexity until both sides of the table are happy.
Helps align business and development goals. Ensures microservices are in fact micro; adjustments to one feature should not affect the entire system.
Better approach than isolated coding in the basement.
If you need to touch half of the system to implement and test new functionality, your separation is wrong