Recommended resources
The freely available resources this lesson will direct you to.
Hello. You have a baseline booking service, focused tests, and a ledger of the help you used. The next step is to turn those artifacts into a 0–5 implementation scorecard. The question is not simply whether the service runs; it is which parts you could implement, verify, and repair independently.
Set aside about 40 minutes. You will review the baseline as it stands, record evidence for each skill, and assign ratings you can revisit after later rebuilds. Do not improve the code just to improve today’s scores.
Review the baseline against its actual brief
Start with the acceptance criteria and API contract you wrote, then inspect the tests and implementation. That order matters: without the brief, it is easy to reward polished code that solves a different problem.
The engineering-practices guide What to look for in a code review gives you a compact lens for this pass. Its questions about design, functionality, unnecessary complexity, and tests apply to a small in-memory service just as they do to a larger change.
What to look for in a code review | eng-practices
Read the engineering-practices guide to distinguish code that merely runs from code that fulfills its intended contract and can be trusted by its tests.
In “Design,” read the design questions. In “Functionality,” read the functionality check. Then read “Complexity,” from its opening question through the warning about speculative future requirements, and “Tests,” from the paragraph beginning “Make sure that the tests in the CL are correct” through its questions about whether tests would fail when code breaks: test effectiveness. Focus on what you can demonstrate in this baseline, rather than features the brief never requested.
Two Go-specific details are worth checking while you inspect: whether returned errors are handled, and whether a failed test would tell you what went wrong. Read only the relevant sections of the Go Wiki’s Go Code Review Comments.
Go Wiki: Go Code Review Comments
Use these Go conventions as concrete review criteria, not as a request to redesign the service.
In “Handle Errors,” read the paragraph beginning “See” the Effective Go errors guidance; focus on the sentence about returned errors. In “Useful Test Failures,” read from the opening advice through the example showing an actual value and a wanted value. Check whether your own test failures would identify the request or input and the mismatch.
For this review, scope is a constraint. An in-memory create-and-get slice should be judged on its stated routes, contract, failure case, package boundaries, and tests. Do not mark it down for lacking PostgreSQL, contention control, or production operations; those belong to later missions.
Define what a number and a color mean
Use the same anchors across the scorecard. A score measures demonstrated implementation capability for a specific baseline task, not seniority or confidence in explaining the topic.
| Score | Evidence required |
|---|---|
| 0 | You attempted the task but could not produce a usable part, even with the help recorded. |
| 1 | A part exists chiefly because you followed a supplied solution; you cannot yet explain or repair it reliably. |
| 2 | You can assemble and verify a part, but task-specific help made substantial implementation decisions, or you need substantial guidance to repair it. |
| 3 | You made the main implementation decisions using at most API reference or conceptual guidance, but an important contract, correctness, or verification gap remains. |
| 4 | You implemented the baseline task independently, verified its required behavior, and can trace and repair relevant failures; only minor gaps remain. |
| 5 | You have also reproduced that capability independently from a blank starting point or on a meaningful variation, including verification and repair. |
“Independently” does not mean recalling every Go API from memory. Looking up a method signature is compatible with a 4 or 5. Adopting booking-specific code or assertions supplied by another source is different: until you reproduce that portion yourself, cap the affected implementation skill at 2. Keep the verification you performed in the evidence column; do not relabel the supplied work as independent.
Translate scores into quick status indicators: green = 4–5, yellow = 2–3, and red = 0–1. Use unrated when evidence is missing or the task was never attempted. That is more honest than treating a missing record as proof of failure. These colors describe your current skill evidence, not whether the service is safe to deploy.
A 5 will usually remain unproven at this point. One successful implementation is evidence; a later independent reproduction is stronger evidence that the skill is yours to reuse.
Build the scorecard from inspectable evidence
Take roughly 15 minutes with your repository, contract, test output, and lookup ledger. Record the commit or repository state you are evaluating so that later changes do not silently rewrite the baseline. Run go test ./... and go vet ./...; record the results without assuming either command proves that every requirement is met. If useful, run gofmt -l . to identify formatting discrepancies. Preserve any failures as evidence rather than fixing them before scoring.
Use these five rows. For each one, note a file and function or test name, a command result where relevant, and the lookup-ledger entry that affects independence.
| Capability to rate | What would count as baseline evidence |
|---|---|
| Requirements and contract | Written acceptance criteria and assumptions; routes, request/response shapes, and failure behavior that can be compared with the implementation. |
| Blank-repository setup and boundaries | A runnable cmd entry point, purposeful internal packages, and dependencies you can trace in one direction without circular or unnecessary abstractions. |
| Create-and-get implementation | The requested HTTP behavior working through the assembled service, with stored bookings retrievable by the agreed identifier. |
| Testing and debugging | A happy-path and a failure-path test with contract-based assertions; failures that identify the mismatch; evidence of how you diagnosed a problem. |
| Implementation ownership | Your lookup ledger showing which decisions you made, which exact APIs you checked, and any task-specific implementation you adopted. |
This is an assessment of implementation, so keep explanation and execution separate. “I can describe the route design” is useful context, but it does not substitute for a working route. Equally, a passing test is weak evidence if it asserts only that the response is nonempty or if its expected status was copied without checking your contract. Ask of each test: would it fail for a plausible broken version of this endpoint? You need not make extensive changes to answer that; inspect its assertions and, if safe, temporarily introduce a local mismatch, observe the failure, and revert it.
A compact entry might look like this:
Create-and-get — 3, yellow.
internal/...contains the create and lookup path; the HTTP test passes through the assembled router. I chose the route and storage behavior from my contract and used documentation for an exact HTTP API. The test does not yet check one response field promised by the contract. Next proof: add that assertion unaided and confirm it fails when the field is omitted.
That is an illustration, not a judgment about your repository. A different baseline might pass both tests yet earn a 2 on implementation ownership because externally supplied code determined the handler and assertions. Conversely, a failed test may coexist with strong evidence that you independently found and isolated the defect. Record both facts rather than averaging them away.
Make the ratings useful for the next mission
Finish with one evidence-backed sentence per row, then select at most two targets. Prefer the gaps that obstruct independent implementation over cosmetic improvements. For each target, state a future proof you could observe: “rebuild this handler without looking at the existing one,” “derive and write the missing contract assertion,” or “trace this error from request to response and repair it.” Do not promote a rating merely because you now understand a reviewed solution; promote it when new work demonstrates the skill.
Keep the scorecard and lookup ledger alongside the baseline snapshot. Today’s result is a starting measurement, not a verdict. Its value comes from making a later comparison possible: which capabilities turned green through independent work, and which still depend on being shown a solution?
You now have a consistent scale, traffic-light ratings, and a way to attach each judgment to code, tests, or a recorded decision. The next module hardens the booking slice with explicit domain rules. Carry this baseline forward unchanged as a reference point: stronger implementation will be easier to recognize when you can compare what you build next with what you could demonstrate today.