Breaking Projects into Parts

This follows my article Learning and the Subconscious Bullet Points, in which I made the following claim (paraphrasing):

Learning projects should generally be broken into parts which take at most a week to complete.

I’m currently reading a book which I started over a week ago. Some books are very difficult to read in under a week. How does that work?

The book-reading project can be divided into parts based on chapters, sections within chapters, pages or days of reading. It’s preferable to use natural dividing points within the book, but possible to divide it up more arbitrarily, e.g. every 100 pages.

I’m reading a non-fiction book with clear distinctions between chapters. All chapters are related to the broad theme of the book, but new chapters change topic from the previous chapter rather than directly continuing the previous line of thought. So the chapters work well as breakpoints.

I’ve read fiction books where, sometimes, two chapters in a row are about the same characters doing the same stuff. Sometimes multiple chapters even cover the same scene (e.g. a long battle). In that case, some chapter boundaries don’t work very well as breakpoints. Some new chapters do work well as breakpoints, but it’s often hard to know which those are until you reach them and read the first page of the next chapter and see that it’s about different characters or a different place, has a time gap, or at least changes scene. In these books, chapters are often short, and the text fairly easy to read, so it’s not very hard to read multiple chapters in one day.

Some novels end chapters with cliffhangers – intentionally bad breakpoints – to try to get you to keep reading.

What’s the point of dividing a book-reading project into parts? What difference does it make? What does it matter if you read the book and call it one big project or a bunch of small projects?

You evaluate the success or failure of every project part (sub-project). A project part is a chunk that you will judge. And it needs to be judged mostly independently, in isolation, by itself. You can take into account some context, but the judgment should be more focused on the chunk itself than the context. If you can’t look at and evaluate a part mostly by itself, then it isn’t a valid sub-project.

So another way to view it is: when learning something, you shouldn’t go more than a week without evaluating your progress. You should be making judgments about success and failure every week at minimum. It’s common and good to make multiple judgments per day. But it’s OK if some sub-projects take longer and you try to get further along before judging. Most learning activities should be finished and judged in under a day, but a week provides a reasonable upper limit. Going near the limit should be uncommon.

In other word, for any larger learning projects, you need to find milestones along the way rather than waiting until the very end to figure out if the project is working. This is similar to how businesses have targets and deliverables within a project, and keep track of whether the project is going well during the middle of the project. They don’t wait until the end to find out of it’s on schedule and within the budget.

How do you evaluate success or failure for a sub-project?

Each sub-project must have a goal. If your overall goal is to learn from a book, you can evaluate whether you learned anything from each chapter (or other sub-part). If you didn’t learn anything from a chapter, you should analyze what’s going on and reconsider whether to finish the book.

If your goal is to enjoy a book, you should enjoy each sub-part. If you don’t, then investigate what’s going on and consider changing your plans. Some projects require success at all their sub-goals but other projects don't. Enjoying a book is the type of project where you could fail at a few sub-goals (there could be a few boring, unenjoyable parts) but still have a successful project overall.

Broadly, all big projects need sub-goals. Want to learn to touch type? You can divide that into sub-goals like learning the home row, top row and bottom row. Those projects can be divided into sub-sub-goals of learning each individual letter. You can also divide typing into parts by hand, by finger, or by a section of several adjacent keys. You could also divide it up by vowels and consonants. Or you could practice typing a limited set of words. Learning the numbers and symbols row might come after you learn to type letters and common punctuation marks. Each of the three rows of letters is essential to typing, but typing numbers is less common, so it could be a sub-part of your project, or you could save numbers for a second project later. It might be easier to learn to type the numbers after you’ve been typing words for a year and gotten more experience as a typist.

Sub-projects can be chunks to automatize.

Another way to view it is that you should automatize some skill (physical or mental) at least weekly when doing learning projects. Longer projects should be divided into skills that are learnable within a week. In this case, a sub-project length of several days is common, though you might do a few sub-projects at once. The reason is that spreading practice out is helpful. You can think of it in terms of spaced repetition. You may even want to do more practice after the first week (you could view that as a separate memory-reinforcement project), but you should have some skill basically learned within a week (additional practice is for better long term memory, not initial learning). If that’s too hard, break it into smaller parts like sub-skills.

Even typing a single letter can be broken into parts. Consider typing “E”. Moving your finger or hand up to the top row is a part. Positioning your finger over or on the “E” key is a part. Pressing the key is a part. Returning your hand to where you started is a part. Pressing shift is another part, which could be divided into multiple parts like pressing “E” was. And you can learn “E” and shift separately, then have another sub-project to combine the two actions into one simultaneous action.

If you’re trying to automatize finding the verbs in a sentence, you could break that into a sub-project of only finding different forms of “be” (like “is” and “are”). If you actually practice that with dozens of practice sentences, you could get good at it in under a week. If you find that hard, you could split it into sub-projects like only doing “is”, or maybe you should first do a separate project to research what a “verb” is.

Each of these sub-projects lets you evaluate success of that part. You could e.g. do worksheets which can be graded (by yourself or someone else) based on whether you missed any of the target verbs and whether you circled any of the wrong words.

You can look at each typing motion and see if it fits your goals for how you think typing should work (you might find some pictures or videos of correct typing motions and hand positions). You can record video of yourself typing and then play it in slow motion to check if you’re doing it as intended when you type quickly. When you type very slowly you can watch your hands and see if you’re doing it the way you want, but when you type quickly it’s hard to see. It’s also important to learn to type without looking at your hands or the keyboard, in which case you need other ways of evaluating your success, such as seeing what letters appear on screen, having a good feel for whether your fingers are in the right places, feeling whether you strike keys in the center not on the edges, or measuring how many words per minute you’re typing.

When reading books, if you want to use their content in your life, you need to find practicable skills. If you just read and think, you’ll end up with ideas you can use in conscious thought (if you don’t forget), but this won't translate into action well. If you figure out how to take relevant actions, then there's something there you could practice.

Novels are often read for entertainment, not for practical value. But they can provide e.g. examples of relationships between people or examples of how to talk to others. They might have examples of leadership, asking productive questions, or facing adversity without just giving up. You could take examples of social interactions from a novel, come up with some similar situations, and practice writing some dialog of your own (and include descriptions of relevant non-verbal stuff like facial expressions).

If a book is about abstract concepts, like philosophy, you can think about in what situations (including working with certain types of ideas) the concepts apply. You can practice both recognizing when they apply and applying them. Recognition of when to use an idea is really important to actually using it in your life, but practicing that is commonly neglected.

Suppose you're reading a philosophy of science book. You could create or find a list of many scientific scenarios. If you don’t know how to do that, you could base it off a biography of a scientist, a scientific textbook, or a popular science book with different topics and authors for each chapter. Doing that would be a sub-project and you could evaluate success by whether you create a scenario list. Then you could think through whether and how the philosophy of science concepts apply in those scenarios. You could also do things like read the start of a real scenario, predict what scientists will or should do, then read the rest. You could critique the actions of scientists or critique academic papers. Those are ways to get more practice and learn more, but they’re pretty advanced.

Failure is OK.

If you work on a project for 5 days and fail, that doesn’t mean it took more than a week. If you reach an evaluation of success or failure within a week, that's on time. At least you didn’t spend months before realizing you failed. Recognizing failure early is useful. The time for a sub-project is the time to evaluate whether you succeeded, not the time to succeed. If you fail, you can try again, though you usually should succeed at a few other related/relevant small projects before trying again. Try to keep the number of times in a row that you fail small. And before trying again, you need a new plan. Don’t just try to do the identical thing again. The new plan can be very similar to the old plan, but you should make at least one change that is designed to avoid failing in the same way again.

Having multiple failures in a row is exponentially bad. Two is much worse than one. Three is far worse than two. Four means you’re really misjudging what projects you can succeed at. Five should basically never happen. After a failure, do something easy to get some sort of success. If you accidentally get to two failures in a row, do something super easy next. If you somehow reach three failures in a row, do pretty much the easiest thing you can think of next. And to avoid successive failures, make sure to do at least one other project before you retry something you failed at. It’s best if you can have a success on the same topic as the failure, so you can avoid repeated failures on a per-topic basis too, but at least you can succeed at something else.

Put another way, if you fail at a project, you should halve the difficulty for your next project (or reduce the difficulty even more if you think you should). This is exponential backoff. If you managed to halve the difficulty four times and still fail again, you were working on a really unrealistic project to begin with. If the first project difficulty is 100 and you fail, try 50, and if you fail again try 25, then 12, then 6. And in general if you can’t confidently succeed at a difficulty 50 project, you shouldn’t be trying a 100 at all. The maximum difficulty project you should try is maybe 20% more than your best success, not double. And you should look at difficulty on a per-topic basis: if you succeeded at an 70 difficulty chess project and a 40 difficulty cooking project, then your next cooking project should be up to 48 difficulty, not 84.

Note: Sometimes you can quickly go through in the early stages when you have a lot of skill that carries over from other topics, and you can slow down when you start encountering some difficulty. An adult probably doesn't need to do a 2 difficulty cooking project, then a 2.4, and so on. They could just do 5, 10, 15, 20, and keep going up by 5 until their first failure. That would let them more quickly find the skill level they already have from seeing cooking on TV, learning many other skills, doing small amounts of cooking in the past, etc. Basically, if you have zero failures on a topic, you can increase project difficulty by more than 20% to try to more quickly find your current skill level, and once you have one failure then you need to slow down and start learning new things.

The important issue is failed projects not failed actions. If you’re practicing basketball shots but the ball doesn’t go through the hoop, that isn’t a failed project. If you miss five times in a row, that’s probably fine too. When doing a project you need to have a goal and evaluate the success of the project based on the goal. Your goal might be to practice until you get five successful shots in a row, and to do that within three days. Or your goal might be to raise your average success rate. Or your goal might be to change the way you move your arms when shooting the ball. Or your goal might be to practice every day for a week without missing any days. Or you might be a beginner with a goal of getting a feel for basketball to see if you like it and see how much natural talent you have.

This doesn’t mean you can’t try anything hard. It means you should set realistic goals. If your goal is “Try X to see what it’s like (to gain some information about whether you want to do some projects to work towards X)” then that’s probably an easy project which you’ll succeed at even though “Learn to do X within a week” would be a hard project that you’d fail at. Failure often comes from overconfidence, like expecting to learn something or succeed at a task when you should be doing an exploratory project. If in doubt about how difficult a project is, set a goal like “Try X and maybe succeed but maybe not and it’s fine either way”. You shouldn’t use goals like that for everything, but you should use them when they make sense. That kind of goal lets you plan around maybe not succeeding at X, rather than making plans that rely on X. Goals need to be set honestly. If you’re in genuine doubt and would be happy just to try something, then you can set a goal that way. If you’re highly confident and would be dissatisfied without success, then set your goal that way. Don’t lie to yourself and pretend to be just trying something out, or exploring, when you actually want and expect to succeed at it now.

The same actions and results can be success or failure depending on what your goal was. Setting good goals is a key issue that people should generally put more thought into. Spending your time on the wrong goals is inefficient and will give inaccurate feedback about how your life is going. You need goals that accurately correspond to what you want in life, so success at your goals corresponds to success at your life.

Your success rate on projects and sub-projects should be well above 50%.

A success rate over 80% is common but it depends on what you’re doing. If you’re doing original research, or you’re a beginner who is struggling to get started, then you might not reach 80%. (Learning how to set exploratory goals well, and avoiding arrogance, can actually keep your success rate over 95% for basically everything, whether you’re a beginner or expert.) If things are going smoothly and you have helpful educational materials to support your learning, then success rates over 90% are common. If you’re having a hard time, you should try to find easy enough sub-projects to usually succeed. They may have to be pretty unambitious. If you’re doing something extremely hard that where no one would have much success at the overall project, you should still be able to succeed at many sub-parts such as trying something to see if it works or not (so ruling it out is a success at your goal). While it’s fine to take risks and fail some, if you want to build up to a really hard goal, you should accumulate lots of small successes.

Is it cheating to pad your success rate numbers with some really easy (sub) projects? No! As long as they’re a little bit productive/useful, then that’s more like “exactly what you should be doing for the majority of your (sub) projects” rather than cheating. If your overall, average success rate is too low, you should try to improve your numbers by doing smaller, easier sub-projects that you can have a high success rate at. You should view that positively as a standard part of learning, not view it as anything like cheating or padding statistics.

Your success rate on whole, big projects, involving many sub-projects, should also be high. You don’t want to put a bunch of work into something and fail. You should be very careful with big, risky projects and maybe not do any. Most big projects shouldn’t have much risk. It’s possible and reasonable to go through life – and be ambitious and get a lot done – without any failures at big projects. Like an oil company might build 100 very expensive oil rigs in the ocean and have a 100% success rate of getting them built and functioning: none of them ever just collapse half way through construction or accidentally leave the drill out of the design and therefore fail to get any oil.

Repeated failures in a row are really bad. It’s important to experience success, see what it’s like, remember how it works, and not spend your life failing over and over. And one failure that involve a lot of resources, like dozens of sub-projects, is bad too.

One thing that reduces risk is valuing the journey more than the destination. Then if you don’t reach the destination, the project could still be a success. You might have no regrets and still think it was worth doing.

Lying to yourself when writing down a goal won’t help. If you actually really wanted the destination and are disappointed and regretful, then you’ve experience failure no matter what you said your goal was. On the other hand, if you said the destination was your goal but you’re still happy to stop short and you found the journey really valuable, then that’s success. It’s your actual, internal goals that matter most. You should put effort into making your stated goals match your real goals. Also sometimes your goals can change as the project goes along. You might start to get your hopes up and start wanting some more ambitious stuff, which leads to risk and perhaps failure. Or you might see things aren’t going well and start changing your goals to be easier, either to pretend you didn’t fail by moving the goalposts, or because you actually changed your mind about what goals to aim for.

Don’t use vague, multi-year goals to avoid knowing whether your actions are productive.

People sometimes choose very big, hard goals like “develop artificial general intelligence (AGI)” and then avoid having milestones or sub-projects. That lets them go years without anything to show for it but without acknowledging failure. They excuse this because the project is so hard that even trying and failing for their whole life would allegedly be reasonable. AGI is something that seems worth the entire careers of thousands of people to develop. This is a way to avoid visibly failing to fool yourself or others. You can say “I may have investigated a dead end, but people needed to explore many dead ends to help narrow down where to look – there was no way to know it was a dead end without trying it.” And sometimes that’s true, but sometimes it's an excuse.

The point of the big, vague goals strategy is to avoid evaluating yourself as failing. Even if you fail to produce any positively useful results, you can claim you made a good try at it and creativity is unpredictable and also you helped rule out some dead ends. Using overly difficult or vague goals, and not expecting success until far in the future (possibly after you’re dead when others might build on your work), are defense mechanisms that unproductive people use to hide that they aren’t actually clever, productive intellectuals. They’re usually primarily trying to fool themselves, but they may also be able to fool others and even get millions of dollars of startup or research funding.

For a comparison, imagine a department manager at a big company company said “I want a big budget to run my department, and I’m going to try doing some hard, unusual stuff that might not work out.” Then every year he did nothing to evaluate his progress, reported no metrics, tracked no statistics, spent all the money, and said “I haven’t succeeded yet but that’s OK because it’s a hard goal with a big payoff if it works”. That manager would be told to change his approach or be fired. Sometimes research and development workers get away with similar behavior, but they shouldn’t. It’s always possible to succeed at some relevant sub-goals, evaluate your success at something, explain your sub-goal success to others, etc. You don’t have to wait until the end of a big, hard project – where you succeed or fail at the overall big goal – in order to evaluate whether you’re getting anywhere. If you can’t figure out any milestones that you’re reaching and can evaluate, then you’re probably wasting your time. (Or else you don’t know how to manage big, hard projects, in which case you should learn that skill before doing one, or else work with a project manager who has that skill. Some researchers are productive despite poor project planning skills because someone else helps do that job.)