uuid: - value: b9297a41-9a9a-46e4-a7a9-4281ff5c88e7 langcode: - value: en type: - target_id: daily_email target_type: node_type target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7 revision_timestamp: - value: '2025-05-11T09:00:24+00:00' revision_uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 revision_log: { } status: - value: true uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 title: - value: 'Decide, automate, document' created: - value: '2023-12-29T00:00:00+00:00' changed: - value: '2025-05-11T09:00:24+00:00' promote: - value: false sticky: - value: false default_langcode: - value: true revision_translation_affected: - value: true path: - alias: /daily/2023/12/29/decide-automate-document langcode: en body: - value: |
Decide, automate, document
Here are three steps to making decisions, such as introducing new tools and processes:
Decide.
Automate.
Document.
First of all, a decision needs to be made about what you will introduce.
It could be whether to write automated tests, use static analysis, choose which coding standard to use, or make architecture decisions about how you want to build your application.
Once you've decided and added the tool or process, automate it if you can.
A CI pipeline or Git Hooks can run tests and checks automatically to know if the code complies with what was agreed upon rather than relying on this being done manually.
Finally, document it so that it's available for others to read and reference, including new team members.
Ensure to document why this was added, what problem it solves, any alternatives that were considered and any side effects or consequences. Technical design documents and ADRs (architectural decision records) are great for this!
In the future, you may want to revisit the decision and decide if it's still correct, and you'll appreciate having the information documented.
format: full_html processed: |Decide, automate, document
Here are three steps to making decisions, such as introducing new tools and processes:
Decide.
Automate.
Document.
First of all, a decision needs to be made about what you will introduce.
It could be whether to write automated tests, use static analysis, choose which coding standard to use, or make architecture decisions about how you want to build your application.
Once you've decided and added the tool or process, automate it if you can.
A CI pipeline or Git Hooks can run tests and checks automatically to know if the code complies with what was agreed upon rather than relying on this being done manually.
Finally, document it so that it's available for others to read and reference, including new team members.
Ensure to document why this was added, what problem it solves, any alternatives that were considered and any side effects or consequences. Technical design documents and ADRs (architectural decision records) are great for this!
In the future, you may want to revisit the decision and decide if it's still correct, and you'll appreciate having the information documented.
summary: null field_daily_email_cta: { }