I remember early on in my programming education having subroutines pounded into my head. I learned them grudgingly, because nothing that I'd written so far was

I remember early on in my programming education having subroutines pounded into my head. I learned them grudgingly, because nothing that I'd written so far was complex enough to need them. It was always simpler to just write my <100 line program without any functions/subroutines. Things got more complex. Named subroutines started seeming logical to encapsulate certain behaviors. Eventually, it became natural to think "I wish this part of the program were separated out and implemented elsewhere, so that I could treat it as a solved problem." That's about the point where a divide-and-conquer approach started occurring to me, at least in a limited context. That context expanded over time.