the music of the hemispheres

I slowly worked my way through Ian McGilchrist's The Master and His Emissary, his longest study into the division of focus of the left and right hemisphere of the brain and its possible implications for how societies construct themselves and evolve over time. 

Even if you are skeptical of the importance of the physical division in how our minds come together (though I think McGilchrist makes an excellent and well-researched case - I mean like 1/5 of the book is citations!) I think it's clear that there are several spectrums. In McGilchrist's view, the left hemisphere - the one that guides the right side of the body - tends to be very concerned with what it can control. It is reductionistic, it likes to categorize, it tends to isolate. In comparison, the right hemisphere is takes in the world as it is. It is holistic, everything is context-based.

Computer programming is intensely reductionistic. You solve a problem by breaking into tiny pieces. When explaining it to non-programmers, I tell it's like breaking a recipe into steps for an idiot chef. 

If you really push this idea, you get explanations for things like functional programming - the usefulness of completely isolating a bit of computation from context. Similar for unit tests: an extremely fine-grained way of studying every little pieces-part in isolation. 

McGilchrist worries that the left hemisphere (reductionism) tends to swamp the right hemisphere culturally, over time (with some counter-swings of the pendulum) but he doesn't think that the right hemisphere should predominate; the most fruitful times are when there's a balance. 

I see the for functional programming. On the one hand, it's easy to understand how code works best if you have clearly defined contracts and a clean room environment each time. On the other hand... it's often tough to get stuff done that way! I think of James Hague's essays on recreating retrogames as pure functional programs - if you think about all the state in even a humble game like Pac-Man: all the dots, the scores, the monster positions, etc - you REALLY have to jump through hoops to avoid terrible anti-patterns (whole state in, whole state out) and I begin to suspect it's would never have a good effort/reward ratio for forcing these games into the modality.

Similarly for unit tests. In my experience, programming bugs are an emergent property! In my experience, very few bugs are because of a blatant mistake inside of a unit... rather they show up as different units are drawn together, and these bugs reflect misunderstandings of contract or context. In other words, yes you want to keep an eye on your trees, but doing so obsessively isn't going to assure you have a valid forest. Higher levels of testing are critical, and to the extent resources put into testing one level might take from testing at another level, I would prefer the higher level views (that will, in turn, exercise the code at the lower levels.) But - it's a balance. (But my relative disinterest in unit tests is a rather unpopular view to people whose intuition believe it's THE key to keeping projects under control.)