When I teach kids to code, I start with Pong. Two paddles, a ball, a score, and a game most of them have never seen but understand instantly. It is old and it is simple, and within ten minutes something they typed is moving on the screen. I have taught enough of those sessions to believe that the first ten minutes decide whether the rest of the lesson happens at all.
I think the first week of an engineer's onboarding works by the same rules.
Something real has to move early
A kid who has a ball bouncing before the first break is a kid who will sit through the explanation of what a variable is, because the variable is now the thing that controls the ball's speed. A kid who gets the explanation first, with the ball promised for later, is already looking at the clock.
An engineer in their first week is the same. I think the goal of week one is a real change, however small, in the real codebase, through the real pipeline, into something that runs. Not a tutorial project and not a reading list. A one-line fix that ships is worth more than a week of context, because the context now has something to attach to.
One idea at a time
Pong is a sequence of single ideas. Draw a rectangle. Make it move. Make it stop at the wall. Make it bounce. Each one is small enough to get right and each one makes the next one necessary. The moment I try to introduce two ideas at once, the questions stop, which is never a good sign.
Onboarding tends to do the opposite. It front-loads everything: the architecture, the history, the tooling, the team norms, all in the first three days, most of it to someone who has nothing to hang it on yet. I think the better shape is a sequence of small real tasks, each one introducing the one new idea the task needs, with the architecture talk arriving when the task finally requires it.
Breaking it is the lesson
The best moment in any Pong session is when a kid changes a number to something absurd, the ball disappears off the screen, and they have to figure out why. That is the first time they are debugging, and nobody told them to.
An engineer needs the same thing: a way to break things safely in week one. A local environment that actually runs, a test suite they can watch fail, a branch where nothing matters. I think the speed with which a new engineer can break the system and recover is the single best predictor of how fast they will become useful, and it is almost entirely under the team's control.
A person, not a document
I have never had a kid learn Pong from the handout. They learn it from the person sitting next to them, who answers the question they actually have instead of the one the handout anticipated.
Onboarding documentation has its place, and I write plenty of it. But I think the first change should be made with someone, pairing, in real time, with the new engineer typing. It is the fastest way to transfer the unwritten things, and the unwritten things are most of what a team knows.
Pong is not a metaphor I planned. It is just the thing I kept noticing: the sessions that go well start with motion, add one idea at a time, let people break things, and keep a person close. I have not found a reason those rules stop applying when the student has a job title.
Photo source: https://photos.robertstowe.com/flowers