{"course":{"slug":"how-software-changed","title":"How Software Development Changed","url":"https://addaly.com/learn/how-software-changed","level":"intermediate","track":"work"},"lesson":{"slug":"the-missing-rung","title":"Juniors, and the rung that went missing","url":"https://addaly.com/learn/how-software-changed/the-missing-rung","position":60,"of":87,"minutes":9,"answer":"The work that used to make people senior is the work that got cheapest, so the rung has to be rebuilt on purpose.","keyIdea":"The work that used to make people senior is the work that got cheapest, so the rung has to be rebuilt on purpose."},"body":{"format":"markdown","text":"## Name the problem plainly\n\nJuniors used to earn their place doing work that was economically marginal and educationally essential: the CRUD endpoint, the small bug, the test backfill, the config change, the third variation on an existing form.\n\nThat is precisely the work that got cheapest.\n\nAnd the mechanism that made it educational was the struggle. You spent three hours on a bug and came out understanding how the scheduler worked. Take the three hours away and the fix still lands, but the understanding does not arrive. You cannot get the learning without the friction, because the friction was where the learning happened.\n\nSo there are two distinct risks, and it helps to keep them apart. One is fewer junior roles. The other is juniors who ship a great deal while learning less than their predecessors did, and who look fine on every metric for about two years.\n\n## What is contested\n\nEntry-level technical hiring has been weak in several markets since 2023. What is unsettled is why. It overlaps with a rate-driven hiring correction, post-2021 over-hiring, and offshoring shifts, and the studies attempting to separate these disagree with each other. Whether this is a temporary dip or a structural change in how teams are shaped is not something anyone currently knows. Treat confident claims in either direction as marketing.\n\nWhat you can act on is narrower and safer: the skills that hold value are visible from the shape of the change itself.\n\n## What a junior should build now\n\n**Reading.** The ability to take a 500-line diff in an unfamiliar codebase and say what it does, and what is wrong with it. This is the highest-value skill in the new arrangement and almost nobody teaches it deliberately. It is trainable: read merged pull requests in a large open-source project, write your own review before reading the real ones, compare.\n\n**Debugging from evidence.** Reproduce, isolate, bisect, read the stack trace properly, add instrumentation, form a hypothesis that can be wrong. Models are weakest exactly where the information is not in the text: in the running system, the network, the data, the thing that only happens under load on Tuesdays. That is also where the hardest bugs live.\n\n**Fundamentals that do not rot.** What a database index actually does and when it will not be used. What a lock costs. How a request becomes a syscall. Why p99 is forty times p50. Where memory goes. These are what let you smell wrong code without being able to say why yet, and that smell is what makes review fast.\n\n**Writing.** Specs, decision records, review comments, incident write-ups. If specification is now load-bearing, the ability to write an unambiguous page is a technical skill, not a soft one.\n\n**Some work done the hard way, on purpose.** Two hours a week, no assistance. Write the parser, the query planner sketch, the retry logic, the binary search. You are not being efficient. You are building the internal model that lets you review a hundred lines in ninety seconds later. A pianist practising scales is not trying to produce music.\n\n## If you manage juniors\n\nThe rung has to be rebuilt deliberately, because the economy will not rebuild it for you.\n\n**Give them review work, not only writing work.** Have a junior review a senior's change, with a senior reading their review afterwards. This is the fastest way to build judgement and it costs a senior twenty minutes.\n\n**Make them explain code they submitted.** Not as a test, as a routine. Fifteen minutes, walk me through this. If the explanation is thin, that is useful information about the change and about the person, and it arrives early enough to matter.\n\n**Put them on real incidents.** Debugging a live system with a senior beside them is the highest-density learning available, and it is exactly the skill that is not being practised elsewhere any more.\n\n**Do not measure them on shipped output.** It is the one metric the tool inflates most, and it will tell you a junior is doing well for two years, right up until they are asked to do something the tool cannot do.\n\n## The uncomfortable part\n\nIf teams stop hiring juniors because juniors are less immediately productive, they will find in five years that they cannot hire seniors, because seniors are made out of juniors and nowhere else. Every individual firm has an incentive to skip the training; collectively that is a shortage being manufactured on a delay.\n\nYou probably cannot fix that from where you sit. You can decide what your own team does, and you can notice that a team that trains people well will, in a few years, be one of the few places that has them."},"check":{"question":"A junior on your team ships more than anyone else. Their pull requests are clean, they close tickets quickly, and reviewers rarely have comments. What should you actually check before concluding they are developing well?","options":[{"text":"Whether their commit volume is sustainable, since a pace like that often ends in burnout within a year.","correct":false,"tempting":"Cares about a real thing, but it treats high output as necessarily costly effort, when in this case the output may be cheap to produce."},{"text":"Whether their code quality holds up under load testing, since speed often trades against performance.","correct":false,"tempting":"Checks a property of the code rather than the state of the person, and reviewers with no comments would likely have caught the obvious cases."},{"text":"Whether they can explain a change they shipped last month, and whether they can find the bug in someone else's diff.","correct":true},{"text":"Whether they are being given hard enough work, since a high close rate suggests the tickets are too easy for them.","correct":false,"tempting":"Reasonable-sounding, but harder tickets shipped the same way would produce the same gap; difficulty of the task is not what is missing."}]},"prev":{"slug":"a-tool-policy-people-follow","title":"A policy people will actually follow","url":"https://addaly.com/learn/how-software-changed/a-tool-policy-people-follow"},"next":{"slug":"how-skill-forms","title":"Why the hard part was the part that taught you","url":"https://addaly.com/learn/how-software-changed/how-skill-forms"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Juniors, and the rung that went missing', in How Software Development Changed. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/how-software-changed/the-missing-rung (Accessed: 31 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Juniors, and the rung that went missing","courseTitle":"How Software Development Changed","module":{"index":7,"slug":"skill-and-the-missing-rung","title":"Skill, hiring and the missing rung"},"answer":null,"keyIdea":"The work that used to make people senior is the work that got cheapest, so the rung has to be rebuilt on purpose.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"name-the-problem-plainly","runs":[{"text":"Name the problem plainly"}]},{"t":"p","runs":[{"text":"Juniors used to earn their place doing work that was economically marginal and educationally essential: the CRUD endpoint, the small bug, the test backfill, the config change, the third variation on an existing form."}]},{"t":"p","runs":[{"text":"That is precisely the work that got cheapest."}]},{"t":"p","runs":[{"text":"And the mechanism that made it educational was the struggle. You spent three hours on a bug and came out understanding how the scheduler worked. Take the three hours away and the fix still lands, but the understanding does not arrive. You cannot get the learning without the friction, because the friction was where the learning happened."}]},{"t":"p","runs":[{"text":"So there are two distinct risks, and it helps to keep them apart. One is fewer junior roles. The other is juniors who ship a great deal while learning less than their predecessors did, and who look fine on every metric for about two years."}]},{"t":"h2","id":"what-is-contested","runs":[{"text":"What is contested"}]},{"t":"p","runs":[{"text":"Entry-level technical hiring has been weak in several markets since 2023. What is unsettled is why. It overlaps with a rate-driven hiring correction, post-2021 over-hiring, and offshoring shifts, and the studies attempting to separate these disagree with each other. Whether this is a temporary dip or a structural change in how teams are shaped is not something anyone currently knows. Treat confident claims in either direction as marketing."}]},{"t":"p","runs":[{"text":"What you can act on is narrower and safer: the skills that hold value are visible from the shape of the change itself."}]},{"t":"h2","id":"what-a-junior-should-build-now","runs":[{"text":"What a junior should build now"}]},{"t":"p","runs":[{"text":"Reading.","b":true},{"text":" The ability to take a 500-line diff in an unfamiliar codebase and say what it does, and what is wrong with it. This is the highest-value skill in the new arrangement and almost nobody teaches it deliberately. It is trainable: read merged pull requests in a large open-source project, write your own review before reading the real ones, compare."}]},{"t":"p","runs":[{"text":"Debugging from evidence.","b":true},{"text":" Reproduce, isolate, bisect, read the stack trace properly, add instrumentation, form a hypothesis that can be wrong. Models are weakest exactly where the information is not in the text: in the running system, the network, the data, the thing that only happens under load on Tuesdays. That is also where the hardest bugs live."}]},{"t":"p","runs":[{"text":"Fundamentals that do not rot.","b":true},{"text":" What a database index actually does and when it will not be used. What a lock costs. How a request becomes a syscall. Why p99 is forty times p50. Where memory goes. These are what let you smell wrong code without being able to say why yet, and that smell is what makes review fast."}]},{"t":"p","runs":[{"text":"Writing.","b":true},{"text":" Specs, decision records, review comments, incident write-ups. If specification is now load-bearing, the ability to write an unambiguous page is a technical skill, not a soft one."}]},{"t":"p","runs":[{"text":"Some work done the hard way, on purpose.","b":true},{"text":" Two hours a week, no assistance. Write the parser, the query planner sketch, the retry logic, the binary search. You are not being efficient. You are building the internal model that lets you review a hundred lines in ninety seconds later. A pianist practising scales is not trying to produce music."}]},{"t":"h2","id":"if-you-manage-juniors","runs":[{"text":"If you manage juniors"}]},{"t":"p","runs":[{"text":"The rung has to be rebuilt deliberately, because the economy will not rebuild it for you."}]},{"t":"p","runs":[{"text":"Give them review work, not only writing work.","b":true},{"text":" Have a junior review a senior’s change, with a senior reading their review afterwards. This is the fastest way to build judgement and it costs a senior twenty minutes."}]},{"t":"p","runs":[{"text":"Make them explain code they submitted.","b":true},{"text":" Not as a test, as a routine. Fifteen minutes, walk me through this. If the explanation is thin, that is useful information about the change and about the person, and it arrives early enough to matter."}]},{"t":"p","runs":[{"text":"Put them on real incidents.","b":true},{"text":" Debugging a live system with a senior beside them is the highest-density learning available, and it is exactly the skill that is not being practised elsewhere any more."}]},{"t":"p","runs":[{"text":"Do not measure them on shipped output.","b":true},{"text":" It is the one metric the tool inflates most, and it will tell you a junior is doing well for two years, right up until they are asked to do something the tool cannot do."}]},{"t":"h2","id":"the-uncomfortable-part","runs":[{"text":"The uncomfortable part"}]},{"t":"p","runs":[{"text":"If teams stop hiring juniors because juniors are less immediately productive, they will find in five years that they cannot hire seniors, because seniors are made out of juniors and nowhere else. Every individual firm has an incentive to skip the training; collectively that is a shortage being manufactured on a delay."}]},{"t":"p","runs":[{"text":"You probably cannot fix that from where you sit. You can decide what your own team does, and you can notice that a team that trains people well will, in a few years, be one of the few places that has them."}]}],"check":{"question":[{"text":"A junior on your team ships more than anyone else. Their pull requests are clean, they close tickets quickly, and reviewers rarely have comments. What should you actually check before concluding they are developing well?"}],"options":[{"text":[{"text":"Whether their commit volume is sustainable, since a pace like that often ends in burnout within a year."}],"correct":false,"tempting":[{"text":"Cares about a real thing, but it treats high output as necessarily costly effort, when in this case the output may be cheap to produce."}]},{"text":[{"text":"Whether their code quality holds up under load testing, since speed often trades against performance."}],"correct":false,"tempting":[{"text":"Checks a property of the code rather than the state of the person, and reviewers with no comments would likely have caught the obvious cases."}]},{"text":[{"text":"Whether they can explain a change they shipped last month, and whether they can find the bug in someone else’s diff."}],"correct":true,"tempting":null},{"text":[{"text":"Whether they are being given hard enough work, since a high close rate suggests the tickets are too easy for them."}],"correct":false,"tempting":[{"text":"Reasonable-sounding, but harder tickets shipped the same way would produce the same gap; difficulty of the task is not what is missing."}]}],"order":[1,0,3,2],"why":null},"prev":{"slug":"a-tool-policy-people-follow","title":"A policy people will actually follow","minutes":9},"next":{"slug":"how-skill-forms","title":"Why the hard part was the part that taught you","minutes":9}}}