> modularisation is an approach to software construction that I generally tend to avoid - as a human writing code I just find it confusing and high overhead<p>How baffling.<p>Anyone who avoids modularisation or considers it 'overhead' has never worked on a large system; or, has only worked on small over-engineered projects.<p>In large projects, it is physically impossible to 'be across' everything that's happening in the code.<p>The only, and I do mean <i>only</i> way to work effectively in a code base like this is to become familiar with a small part of it, clearly identify the boundaries of 'this part' and make sure that your changes happen only with that context where you:<p>- understand the side effects<p>- understand the domain<p>- can work effectively.<p>That is what modularisation is.<p>It is not 'making an NPM package for lpad'; the rough size of 'code you can keep track of' is very obvious to most people; when the code gets bigger than that you need to break it up into modules with clearly defined boundaries.<p>You then learn the boundaries.<p>The boundaries are smaller than the code.<p>You can therefore work effectively by understanding a subset of the code (my module + the boundaries of the modules I interact with) which is strictly < (my module + the content of the modules I interact with).<p>...<p>Amazingly, the same thing applies to LLMs that applies to people!<p>For small projects, you can just go in and do whatever you like and it'll be fine; for larger ones, you have to split it into smaller parts and do each part independently.<p>Absolutely right... but, surely not surprising to anyone?<p>...<p>Here's a pro-tip for you LLM work:<p>You can easily pick the size to use for modules based on the volume of code inside it.<p>Compare the size and complexity of the API for interacting with the module (class, crate, whatever) with the implementation details. I use 'lines of code + documentation + examples for the LLM to use it' as my vague metric.<p>If you're doing an 'lpad' and the implementation is <= the size of the API, don't bother to make it a module. You're wasting your time.<p>When the implementation gets ~10x the size of the API, split it.<p>It ain't rocket science. LLMs are good at writing glue code from well defined APIs.