Give Junior Engineers One Feedback Loop, Not the Whole System
A four-week plan and a scoring rubric for teaching systems thinking without the overwhelm
Most onboarding plans hand a new engineer an architecture diagram with forty boxes and say, “Read this, then pick up a ticket.” Two weeks later they can name every service and fix none of them.
There is a better unit of learning than the system: one feedback loop. A loop has an input, an output, something that changes behavior, and a way to see whether it worked. A cache’s hit rate, a retry queue, an alert that pages someone. That is small enough to hold in your head and real enough to break in production.
What counts as a good first loop
Pick a loop that is small, observable and safe to touch. A good test: could the junior explain it on a whiteboard in five minutes, and could a mistake in it be fixed within an hour?
Write it down in three lines before you assign it:
- Inputs: what starts it (a request, a message on a queue, a cron tick)
- Outputs: what it produces (a response, a state change, an alert)
- Control points: what a human can change (a TTL, a threshold, a retry limit)
If the junior cannot fill in those three lines after a day of reading, the loop is too big. Shrink it, do not explain more.
The four-week plan
Week 1: Observe. They read the dashboards and logs for the loop and write down what “normal” looks like: typical rates, typical latency, the shape of the daily curve. No code changes.
Week 2: Explain failures. Give them two or three past incidents that touched the loop. Their job is to name the failure mode (dependency down, resource exhausted, bad deploy, bad input) and point to the signal that revealed it.
Week 3: Change one thing. They propose and ship one small change with a prediction attached: “Raising the TTL from 60s to 300s should lift hit rate by a few points and cost us staleness on X.” Predictions are the whole point. A change without one teaches nothing.
Get Coding Guy’s stories in your inbox
Join Medium for free to get updates from this writer.
Week 4: Measure and present. They compare the prediction with what happened and present it to the team in ten minutes, including what they got wrong.
A rubric that fits on one page
Score each dimension 1 to 3. Review it together, not behind their back.
- Spots failures: 1 = notices only loud errors. 2 = notices slow degradation too. 3 = predicts where it will fail next.
- Prioritizes: 1 = treats all alerts alike. 2 = ranks by frequency. 3 = ranks by user impact and cost.
- Mitigates: 1 = fixes the symptom. 2 = fixes the cause. 3 = also prevents recurrence.
- Measures: 1 = “it seems better”. 2 = before and after numbers. 3 = numbers plus a baseline or control.
- Communicates: 1 = hard to follow. 2 = clear to the team. 3 = clear to a non-engineer.
A scored example
Prompt: Login takes about 3 seconds for some users. Find out why.
Answer A: “The system is under load, so it’s slow. We should add more servers.” That scores 1 on spotting failures (no specifics), 1 on prioritizing, 1 on measuring.
Answer B: “p95 login latency doubles at the top of each hour. Database wait time rises at the same moment, and a batch job starts then. I would move the batch job off-peak first, since it is cheapest to try, then check whether the p95 curve flattens.” That scores 3 on spotting, 2 on prioritizing (it did not weigh user impact), 2 on measuring (a plan, not yet a result).
The difference is not intelligence. B names a signal, a cause and a test.
Calibrate, or the scores mean nothing
If two mentors score the same answer differently, the rubric is vague. Once a month, have mentors score the same two anonymized answers separately, compare, and rewrite whichever row caused the disagreement.
Where this goes wrong
- Choosing a loop nobody owns. The junior then has no one to ask. Pair every loop with a named person.
- Skipping the prediction step. Without it, week 3 is just a code change.
- Never widening. After two loops, connect them: what happens upstream when this loop misbehaves? That is where systems thinking actually starts.
Start with one loop this week. Write the three lines, pick the owner, and put the week 4 presentation on the calendar before anything else.
