Byting Off More Than You Can Chew
The first and prefatory note I should mention, regarding this post, is that, for a second, I thought I was the first person to use the expression, "Byting Off More Than You Can Chew". I found it pleasing yet suspicious: Shirley, I couldn't be the pioneer with this cleverness.
Quite realistically, that turns out to be not the case. My mistaken impression was due to incorrect and insufficient googling skills, nothing more. Several internet-searchable sources have the "byte" version of the centuries-old idiom, "to bite off more than you can chew". Alas, I am not the first.
Moving along...
The point of this particular blog entry is to make an observation about an instance of me, taking on more than I can handle in one attempt. Actually a series of instances. And encountering the hard wall of that reality, also, when I ask the LLM code assistant, Claude Sonnet 3.7 with extended thinking, to do the same. As is the case with all LLMs, Claude has a limit on its context window. And as is the case with all humans, I have a limit on my context window (or the human equivalent).
So what is the time-proven approach to getting around the limitation of a context window? Breaking up the too-large task with smaller tasks. When faced with a task that can be separated into a linear series of smaller tasks, this not a difficult operation. However, when faced with a task that is more networked, less clearly separable into discrete tasks, this becomes a difficult operation.
One common issue is losing sight of the main, overall picture. The creation that is made from all the smaller components working together to make the whole. (Yes, the whole is greater than the sum of all parts.) In language terms, losing the vision of the high-level theme, how everything connects, and what meaning is understood from everything connecting. So, too, in programming. Developing smaller units of code can cause issues, when one disregards or forgets the overall picture, by creating requirements or structures that do not mesh well with the overall picture or theme.
But breaking-into-smaller-tasks (project-level decomposition, and then task-level decomposition) cannot be done when emergent behavior continuity is needed. For each small task that gets done and changes the codebase, the emergent behavior will change. If you want that overall behavior to change in specific ways, you need to know how emergent properties will come about from the small task changes. So, really, it's best to decompose the entire effort as much as possible, on paper or whiteboard or your chosen whatnot.
Upshot is: Though it may take extra and seemingly unnecessary effort at first, to make progress and to continue making progress without encountering lots of downtime (wondering, cussing, spinning wheels, etc), the best approach is to plan out the whole damn thing, and to practice project decomposition, and then task decomposition. And to keep breaking the too-big-things into lots of the smaller-things, until you're practically at the quantum mechanics level of code.
(And, because I prefer too much explanation instead of too little, I've put in plenty of C&D [Comments and Docstrings], too.)
Picture (because I'm trying to maintain the first post's visual appearance) of "It's turtles all the way down."
Comments
Post a Comment