Or at least, why this software developer loves Legos:
I have occasional starving artist phases, where I live in the woods studying art, or go back to school for motion graphics, or live in a ghetto writing screenplays. When I want to get back into writing code, I have a trick I use: I buy lots of Legos, and I put them together. (Technic and Mindstorms kits are the best, of course.) I use this trick to re-train my mind in the basic skills of software development, if it's gone all soft and arty at the edges. The trick works marvelously well.
It works because software development is a lot like building Legos. For example, a lot of the time, when you're creating software, you run into some problem. If you're new to development, you blame some component you're working with; if you're experienced, you know it's something you did. Likewise, with Legos, if you're trying to follow the instructions and you can't find a particular piece, it's very tempting to think that they somehow failed to include that piece in the kit, but if you've built a lot of Lego kits -- or you have have good common sense -- you know for a fact that it always turns out that they didn't forget to include a piece, you just failed to see that piece.
What you do in a situation like that is you pick into the pile of Legos, and you start grouping together pieces which are similar to your "missing" piece. There are two reasons to do this: first, if you methodically grab every piece which could be your piece, you're more likely to grab the piece which is your piece. The second reason is that if all the pieces like your piece are in one place, except for the piece itself, that remaining missing piece is more likely to pop out at you visually when you look at the big pile of Legos.
This is a lot like the way that refactoring can expose bugs, design flaws, and similar weirdness. You group similar things together, and this makes the exceptions and the edge cases more obvious and easier to spot.
Another similarity is that there are a few Lego pieces which are almost exactly similar, but not quite, and if you're not paying attention when you put the kit together, putting the wrong piece in place is pretty easy to do. Taking the kit apart to swap out the wrong piece with the right piece is pretty similar to run-of-the-mill debugging, especially when you're dealing with a complicated kit. You take the gears off and put them here; you take the axles out and lay them there. You need them all structured and easy to find, because except for the piece swap, you're keeping everything else as it was. Very similar to fixing a problem in one tiny piece of code smack dab in the middle of an otherwise perfectly good application.
One final similarity, of course, is that putting entirely new designs together is more fun than using instructions, and also harder to do, in the same way that building your own framework is more fun than using somebody else's, and also more work.