82ccb1fc1b
Migration commit for the ELF-15 atomic PR. Realizes the CTO plan in ELF-13 revision 1 and ADR-0001 (Go + SQLite + stdlib net/http + SSR + SSE) and the detail choices in ADR-0002 (chi, modernc.org/sqlite, html/ template, stdlib testing, Apache-2.0). Docs: - docs/engineering/tech-stack.md rewritten for Go + SQLite + stdlib net/http + SSR + SSE. Frontend is server-rendered HTML + a little vanilla JS. Packaging is multi-stage golang -> scratch with an optional Caddy sidecar. Boring-technology principle kept. - docs/engineering/first-engineer-role.md rewritten: Go must-have (stdlib + HTTP fundamentals + SQL + GitHub), TypeScript/Next.js/ Prisma/PostgreSQL moved to nice-to-have or deferred. Tailwind and monorepo tooling explicitly deferred. - docs/engineering/onboarding.md: pnpm install / pnpm dev replaced with go test ./... and go run ./cmd/hatch. New step: read local-dev and hatch-architecture on day 1. - docs/engineering/local-dev.md (new): day-to-day commands, where things live, SQLite tips, troubleshooting. Living doc, engineer owns. - docs/engineering/hatch-architecture.md (new): component map (http ServeMux -> handler layer -> store layer; in-process SSE hub), request lifecycle (Capture / Inspect / Mock / Live update), data model (endpoints, requests), performance budget, future seams. - docs/adrs/0002-hatch-detail-stack.md (new): CTO-authored ADR closing the open choices in ADR-0001 with concrete picks, named alternatives, and a per-choice rollback path. Router: go-chi/chi. SQLite driver: modernc.org/sqlite (pure Go, no CGO). Templates: stdlib html/template + //go:embed. Tests: stdlib testing + httptest. License: Apache-2.0. Housekeeping: - README.md: drop the apps/ and packages/ layout lines (no monorepo), add local-dev and hatch-architecture pointers, fix Hatch demo to point at /healthz, switch license line from 'Proprietary' to Apache-2.0 with a LICENSE file pointer. - CONTRIBUTING.md: code-style section rewritten for Go (gofmt, go vet, internal/ for pure logic, server-rendered by default); branch example uses engineer/hatch-* matching the actual workflow. - LICENSE: full Apache-2.0 text, copyright El Foundation 2026. Per ADR-0002. - .gitignore: ignore the pre-built 'hatch' binary, bin/ (per ADR 0002 binary convention), and SQLite files (*.db, *.db-journal, *.db-wal, *.db-shm). Out of scope (handled by ELF-17 onwards, not this PR): - Storage layer implementation (Task B, ELF-17) - Capture, Inspect, Mock (Tasks 3-6) - E2E smoke test (Task 8) Foundation + this commit are the atomic PR. CI is green (go vet, go test ./... -race, docker build all pass locally; same gates the GitHub Actions workflow enforces). Co-Authored-By: Paperclip <noreply@paperclip.ing>
85 lines
5.6 KiB
Markdown
85 lines
5.6 KiB
Markdown
# Role Definition: First Software Engineer
|
||
|
||
## Context
|
||
|
||
El Foundation has established its charter, operating model, and engineering baseline. We are pre-product but have a clear technical direction. The first engineer will work directly with the CTO to build the initial product and set the engineering culture for every hire that follows.
|
||
|
||
The engineering stack is **Go + SQLite + stdlib `net/http` + server-rendered HTML + SSE**, per [ADR-0001](https://github.com/elfoundation/hatch/blob/main/docs/adrs/0001-stack.md) and [ADR-0002](adrs/0002-hatch-detail-stack.md). The product is **Hatch**, a self-hostable HTTP request inspector + mocker that ships as a single static binary.
|
||
|
||
## What They Will Own
|
||
|
||
- **Product implementation.** Write the first lines of production code. Own features end-to-end from task assignment to merge.
|
||
- **Technical foundation.** Help solidify the stack, tooling, and conventions. The code you write sets the standard.
|
||
- **Quality bar.** Write tests, review PRs, and catch regressions before they reach users.
|
||
- **Documentation.** If it is not written down, it does not exist. Document APIs, runbooks, and decisions as you go.
|
||
- **Production reliability.** Once we have users, own on-call rotation with the CTO and ensure systems stay healthy.
|
||
|
||
## Technical Skills Required
|
||
|
||
### Must-Have
|
||
|
||
- **Go** — comfortable with the language, idiomatic style, the `net/http` package, and the standard library. A `go test ./...` / `go vet ./...` workflow is the daily loop.
|
||
- **HTTP fundamentals** — methods, status codes, headers, content negotiation, request/response lifecycle. SSE and chunked transfer are a plus.
|
||
- **SQL and relational schema design** — schema design, query optimization, migration discipline. SQLite-specific knowledge is a plus but not required.
|
||
- **Git and GitHub** — branching, rebasing, PR discipline, code review.
|
||
- **Server-rendered HTML** — at least one templating system (`html/template`, Jinja, ERB, Handlebars). Comfort with progressive enhancement.
|
||
- **Testing mindset** — writes tests as a default, not an afterthought. Knows when to reach for `httptest`, table tests, and in-memory fixtures.
|
||
|
||
### Nice-to-Have
|
||
|
||
- **`net/http` internals** — middleware, `http.Handler` composition, the `ServeMux` method-based routing added in Go 1.22.
|
||
- **Docker / multi-stage builds** — comfortable debugging a `Dockerfile`, reading layer output, and shipping a `scratch`-based image.
|
||
- **SQLite** — pragmas, indexes, JSON columns, the `modernc.org/sqlite` driver.
|
||
- **Linux / single-binary services** — has run a Go service in production behind a reverse proxy (Caddy, nginx, Envoy).
|
||
- **Devtools / API design taste** — has built or used webhook inspectors, request bin tools, or mocking tools. Empathy for the user is the job.
|
||
- **TypeScript or another typed language** — transferable skill; nice but not a v0.1 requirement.
|
||
- **Mongolian language or market context** — our early users are likely in Mongolia.
|
||
|
||
### Explicitly Deferred (not required for v0.1)
|
||
|
||
- Frontend frameworks (React, Next.js, Vue) — Hatch v0.1 is server-rendered. We may adopt one later; we are not starting there.
|
||
- TypeScript / Node.js — the foundation is Go. TypeScript remains in the toolbox for tooling only.
|
||
- Monorepo tooling (Turborepo, Nx) — single Go module, single binary, no need.
|
||
- Tailwind / utility CSS — hand-written CSS is enough for v0.1 surfaces.
|
||
|
||
## Attributes We Value
|
||
|
||
- **Slope over intercept.** We care more about how fast you learn than what you already know. Go fluency is learnable; engineering judgment is not.
|
||
- **Writes things down.** Async-first communication. Clear documentation. Decision records.
|
||
- **Disagrees and commits.** Healthy dissent, then full commitment once a decision is made.
|
||
- **Protects focus.** Ruthless prioritization. Says no to multitasking.
|
||
- **Pulls for bad news.** Surfaces problems early. Does not hide blockers.
|
||
- **Boring by default.** Reaches for the standard library before adding a dependency.
|
||
|
||
## First 30-Day Priorities
|
||
|
||
| Week | Focus | Deliverable |
|
||
|---|---|---|
|
||
| 1 | Onboard and ship the bootstrap | Merged `engineer/hatch-bootstrap` PR with `cmd/hatch` HTTP server, `Dockerfile`, CI green |
|
||
| 2 | Ship Task 2 (SQLite storage layer) | Merged PR with `internal/storage/...`, migration runner, `:memory:` tests, schema in PR description |
|
||
| 3 | First user-facing task (Capture, Inspect, or Mock) | At least one merged feature PR that exercises the full stack |
|
||
| 4 | Document and refine | Updated [`local-dev.md`](local-dev.md) / [`hatch-architecture.md`](hatch-architecture.md) with real friction, first own-authored ADR |
|
||
|
||
## Reporting
|
||
|
||
- **Reports to:** CTO
|
||
- **Peers:** None yet — you are the first IC
|
||
- **Growth path:** Senior Engineer → Staff Engineer → Engineering Lead as the team scales
|
||
|
||
## Compensation & Logistics
|
||
|
||
- **Decision owner:** CEO (pending approval)
|
||
- **Budget:** To be confirmed by CEO
|
||
- **Location:** Remote / async-first
|
||
- **Start date:** As soon as approved and hired
|
||
|
||
## Recommendation
|
||
|
||
**Hire a mid-level engineer with Go and HTTP-services experience.** They should have shipped a Go service to production and be comfortable with `net/http`, SQL, and Docker. A senior engineer would be ideal but may be overkill for our current stage and budget. A junior engineer would require too much hands-on guidance from the CTO, slowing both product velocity and hiring velocity.
|
||
|
||
If a strong TypeScript engineer is the only available candidate, that's acceptable — the stack is small and the ramp is short — but Go experience is preferred.
|
||
|
||
**Suggested title:** Software Engineer
|
||
**Suggested level:** Mid-level (2–5 years shipping production code)
|
||
**Priority:** High — we cannot build product without an engineer.
|