Build a skill practice loop, not a course collection

A learning plan can look impressive while avoiding the thing you want to become better at. You finish a course on testing but still struggle to choose a useful test. You read about system design but have not explained a trade-off to another person. The missing step may be an attempt you can inspect.

Choose a skill you can demonstrate

Replace a subject with an action. “Learn testing” is a subject. “Given a small feature description, identify a normal case, a boundary case, and a failure case, then explain why each matters” is an action. A reviewer can inspect the result and point to a specific gap.

Scott H. Young’s Get Better at Anything organises learning around seeing examples, doing the work, and receiving feedback. The author describes those ingredients in his public introduction to the book. Our practice plan below applies the idea to engineering; it is not a measured training programme.

Pick a capability relevant to work you can safely attempt. It may be technical, such as reducing a bug to a small reproduction, or communicative, such as explaining a decision’s assumptions. Avoid choosing a vast identity goal like “become a great engineer” as the unit of practice.

Try the decision

A developer has watched a tutorial on database indexes. What turns that into practice?

Watch the same explanation againPredict a plan, change an index and compare measured output

Recognition during a video is not evidence that the developer can diagnose a query.

Next step: Define a demonstrable action.

This is an illustrative decision with stated assumptions. It cannot establish your employer’s policy or predict an individual career outcome.

Study an example for the decisions it contains

In an illustrative example, a developer wants to improve at investigating bugs. They watch an experienced colleague examine a small failure in a test environment. Instead of copying commands, they note each hypothesis, the observation that would distinguish it from another, and why the colleague chooses that check.

Ask for the reasoning that is not visible on the screen. What did the colleague rule out? Which signal was misleading? At what point would they ask someone else? An expert’s final fix may hide the part you most need to learn.

A written worked example can serve the same purpose. Pause before each step and predict what you would inspect next. Then compare your reasoning with the explanation. If the example assumes knowledge you lack, study that prerequisite rather than memorising the final sequence.

Attempt the work and get useful feedback

Now investigate a different small failure without following the example step by step. Use a safe exercise or authorised work. Write down the symptom, your current hypothesis, the check you chose, and what the result changed. The record can be brief; it exists to make your decisions reviewable.

Agree the criteria before the review. In the debugging example, useful criteria might include distinguishing observation from assumption, choosing checks that eliminate plausible causes, and recognising when the next step needs help. Finishing quickly is not the only criterion, especially when the correct answer was easy to guess.

Ask for feedback on the work: “Which check did not add useful information?” is more precise than “Am I good at debugging?” A test result can show that the fix behaves as expected in the checked case. A reviewer can help assess the reasoning and missing cases. Neither alone answers every question.

A useful help request makes the uncertain part visible. Bounded independent delivery provides the surrounding responsibility: practising does not excuse unsafe changes or silent delays.

Change the next attempt, not only its difficulty

Use the feedback to choose the next task. If you jumped to a favourite explanation, practise comparing two plausible causes. If you gathered too much irrelevant information, practise making a smaller reproduction. If you understood the bug but could not explain it, write a short account for a colleague.

Do not repeat the identical exercise until remembering the answer looks like improvement. Change a relevant condition and check whether your method still works. Equally, do not increase difficulty so sharply that every attempt becomes random searching without understandable feedback.

Young’s separate essay on improving skills suggests focused work on component skills while retaining whole-task practice. For a developer, that means returning from the drill to an actual task where you must choose when the technique is useful.

AI assistance can supply hints or alternative explanations, but distinguish an assisted result from what you can do independently. Verify suggestions and use only material you are authorised to share. If a tool supplies the entire reasoning, ask yourself which part of the target skill you actually practised.

Keep the practice bounded and useful

Make a small plan with a task, a reviewer or check, a time boundary, and a review point. The exact duration should fit your situation. A workplace learning task should have agreed capacity; a personal exercise should fit the time you genuinely have.

Keep evidence of change rather than a count of consumed material. Can you now explain a decision you previously guessed? Can you handle a different case? Do you recognise when the technique does not apply? Those are more useful questions than how many hours of video you completed.

Use a short design explanation as practice when the target is judgement rather than debugging. When you are choosing the skill itself, compare the value of depth and breadth against the work you want. The loop starts with a meaningful capability, not with whatever course appears next.