• 👋 Hi, I’m @ACoolmanTelicent
• 👀 I’m interested in making pedestrian things automated, and valuable problems front and center
• 🌱 I’m currently learning about Telicent
• 💞️ I’m looking to collaborate on ___
• 📫 How to reach me probably Frontend team "wall"

I'll try and be precise by default.

But if I can't think of anything better to do, I'll end up biasing toward action BUT with some time, care and effort put aside for cleaning up any confusion I cause.

In the pantheon of holy knowledge transfer techniques:

1. 🏆 Automation (of outcomes)

• The Holygrail of full automation may not exist but its worth the questing to find it
• Example: one command gathers input then runs every app in any environment

2. 👼 Contextual docs/help

• A slight compromise is when the process/idea largely drives itself, but relevant info is added when its needed
• Example: IF telicent-cli stderr includes "network not found>" THEN display "Try 'docker network prune'"
• Example: Project repo description should always be up to date

3. 📜 Documentation

• This is a large compromise
• Some docs are probably better than nothing, but sometimes, even no docs are better than some docs

Then each of these techniques can have holy attributes. For instance:

• conventional/idiomatic: lessen the need for docs, and make editing automation easier).
• discoverable: docs/help/automation scripts that are easily found are better than those that are hard to find

And of course unholy attributes - e.g. dependencies that are not enforced - like test failures that don't block PR

We shouldn't be patting ourselves on the back for creating documentation, we should be celebrating how/when our teammates achieve outcomes

Idle thought: I'd really love a file watched on yarn.lock that give me a big notification saying "Yo, you just changed yarn.lock"

• Commit messages: although relatively permanent, don't self-surface (especially when squashed), and not accessible to non-engineers. Don't over rely.
• Unit tests: Much more worth if done with T.D.D, but T.D.D depends on clear requirements. It is still worth writing tests after the fact.