Chapter 8. Break Problems and Tasks into Small Chunks
Jeanne Boyarsky
You’re learning to program. You receive a small assignment. You write under a thousand lines of code. You type it in and test. Then you add print statements or use a debugger. Maybe you get coffee. Then you puzzle over what you were thinking.
Sound familiar? And that’s just a toy problem. Work tasks and systems are far larger. Big problems take time to solve. And worse, there is too much to hold in your brain’s RAM.
A good way to deal with this is to break the problem into small chunks. The smaller the better. If you can get that one small piece working, then you don’t have to think about it anymore and can move on to the next piece. When doing this well, you want to write automated tests for each small problem. You should also commit frequently. That gives you a rollback point when things don’t work as expected.
I remember helping out a teammate who was stuck. I asked when he had last committed, because the easiest fix would be to roll back and reapply the change. The answer was “a week ago.” Then he had two problems: the original one and that I wouldn’t help him debug a week’s worth of work.
After that experience, I ran a training session for my team on how to break tasks into smaller chunks. I was told by the senior developers that their tasks were “special” and “couldn’t possibly be broken up.” When you ...