Descriptive

Change Log

📖 Semantic Commits

• Should reflect the scope, type & intention of the change
• If trying to cover too much, might be worth splitting it into atomic commits (next...)

Title [max ~50 chars]

📖 Semantic Commits

• Explain further details if needed (what, why, how)
• Reference to sources
  • External: Articles, StackOverflow,
  • Internal: Github issues/PRs
    • ​Tip: "Fix", "Close" Github keywords

Message Body [optional]

⚛️ Atomic Commits

• Cover one and only one thing
• Commit frequently, even when...
  • Code is draft, not perfect nor complete
  • Tests are failing
  • You are fixing/refactoring a previous commit
  • (more on Refactoring & TDD later)
• Reflect you mental model & problem solving process

KISS

⚛️ Atomic Commits

• Tell a story!
• Communication for your PR reviewer(s)
• Self-doc for team / future-self (6mo)
• Dig history & debug regressions

Why?

Pull Requests

🎋Branch Naming

📄 PR Template

Description Message

Concise descriptive message that serves as a summary of the branch. This helps identify the content of the Pull Request at a glance

• What / Why?
• How
• Checklist / Steps
• Demo (code snippet, GIF, Video, you name it!)
• DevOps notes (migrations, env vars, ...)

⚖️ Good Balance

From Reviewer's PoV

• Semantic & atomic change log
• Explain yourself, but no need for a Bible description
• Include demos & instructions
• Keep it digestible & understandable
  • Tip: After submit, make self-Review!
• Avoid building a Cathedral

🧐 Peer Review

• Be thoughtful
• Win-win chance: Learn & mentor!
• Comment but don't block
  • Tip: use a linter/styleguides instead
• Request changes when strictly necessary
• Ask questions instead of pointing for errors
  • Ex. This is wrong, we should always use a RegExp here!
  • Vs. Do you think a RegExp would improve performance?

https://twitter.com/arturovm/status/1319407229364170752

Iterate

Better & Faster

👩‍💻 Better Programmer

• Planning before throwing LoC's
• Problem solving skills
• Use common sense
• Small steps: Practice Refactoring
• Clear Specs: Practice TDD (Test-driven development)

🎳 Better Team

• Constructive discussion
• Sync & async collaboration
• Beat Ideas (code), not individuals
• Reach common knowledge & understanding
• High-level design & architecture
• Avoid:
  • Analysis paralysis
  • Getting stalled (one draft away)
  • Inherent Biases
  • Impostor syndrome

💻 Better Software Products

• MVP: Quick iteration & learning feedback loop
• Expose to end-users: Ship early, ship often
• Better quality, less bugs into Production