Dev Team - Culture & Expectations

This document defines how we work as engineers, how we communicate, how we treat each other, and what is expected of every contributor to our codebase.

Vessel Vanguard’s engineering team builds software used by vessel owners, captains, and operations teams who rely on accuracy, reliability, and practical workflows. Our job is to deliver high-quality, stable, predictable software that maritime professionals trust.

We are a small team with big impact — which means clarity, ownership, and consistency matter more than anything.

Our Engineering Values

  • Reliability First: We write code that works — today and in six months.
  • Clarity Over Cleverness: Readable code > fancy code. A new developer should understand your PR with zero explanation.
  • Continuous Improvement: We look for ways to improve process, quality, and team experience.
  • Leave Things Better Than You Found Them: You don’t need to fix everything — just one small improvement each time you touch a file.
  • Collaboration, Not Silos: We communicate early, ask questions, and keep everyone aligned.
  • Teach Through Code Review: Reviews are collaborative and constructive. We critique code, not people.

Expectations for All Developers

Respect the Branching Strategy

We follow a simple branching model:

  • main = production
  • develop = integration
  • feature/* = short-lived branches
  • release/x.y.z = testing/freeze branches
  • hotfix/* = urgent production fixes

No personal long-lived branches. No stale branches left hanging.

Feature Branch Discipline

Every task → its own feature/xyz branch. Rules:

  • One branch = One task
  • Keep branches small
  • Keep branches short-lived
  • Always pull the latest develop before branching
  • Delete your branch after merge

Pull Request Expectations

Before opening a PR:

  • Your code must compile
    • No broken UI, no failing build.
  • Your code must be tested
    • You test what you built — this includes UI flows if applicable.
  • Your PR must be clean
    • No commented-out code
    • No console.log
    • No debug statements
    • No unused imports
    • No esLint errors
    • No Prettier erros
  • Your PR must include description + screenshots
    • Explain what changed and why.
  • Your PR must respect naming conventions
    • Branch names, commit messages, and filenames should follow standards.

Ownership Expectations

You own

  • Your code
  • The bugs you introduce
  • The documentation of your features
  • The quality you deliver

Reliability & Production Expectations

  • Production is sacred.
  • Never push directly to main
  • Never patch quickly without thinking
  • hotfix/* branches are only for real emergencies
  • All production changes must be reviewed
  • Feature flags encouraged.
  • If a feature is risky → put it behind a flag.

We don’t blame; we fix and improve.

Expectations for All Developers

As a developer:

  • Review PRs promptly
  • Ask for clarification when unclear
  • Suggest improvements, never shame
  • Approve only when confident

As a Pull Request author:

  • Respond to feedback quickly
  • Never argue — discuss
  • Commit fixes as incremental commits (we squash later)

Testing Expectations

Minimal expectations:

  • Validate your feature works on Chrome + Safari + Microsoft
  • Validate no regressions in surrounding UI
  • Validate input validation & error cases

For backend features:

  • Validate endpoints via Postman or API tools
  • Confirm schema changes
  • Confirm database migrations
  • Confirm logs are correct

For fixes:

Handled on the server – Common strategies:

  • Reproduce the bug
  • Prove the bug is fixed
  • Test common side effects

Communication

Communicate early:

  • If you’re stuck for more than 30 minutes, say something.
  • If you’re unsure of requirements, ask.

Keep the team updated:

  • Daily check-ins
  • Clear blockers
  • Honest estimations
  • No silent rework
  • Document as you go
  • Your PR description should be a mini-doc explaining your changes.

ProfessionalConduct

  • Be kind and helpful
  • Give and accept feedback gracefully
  • Avoid ego, blame, or defensiveness
  • Collaborate to create our best work
  • Support junior developers

Summary: The 10 Golden Rules

  • Use the correct branch every time
  • Delete your branch after merging
  • Keep PRs small and clean
  • Explain your work clearly
  • Test everything you touch
  • Follow naming conventions
  • Ask questions early
  • Review code respectfully
  • Take ownership of your features
  • Help create a positive engineering culture