Two masters

I'm generally a big fan of learning by doing. Learning about something is very different from learning how to do something, and although your analytical self might be perfectly happy with understanding the way something works, you're never really going to know how to do it until your inner child understands it too. It makes sense to learn by doing real(ish) projects too, because that way your practice is as close to the performance as possible.

But there's an issue with this: learning by doing is serving two masters. One of them wants you to get the best outcome for the project, and the other wants you to get the best outcome for yourself. Consider: what if there's a slow, methodical way to do something that will teach you about proper form, or a fast and hacky way that will just get the job done? Sometimes (though not as often as people think), it makes sense to just do it the hacky way to get the project out the door, even though that's only teaching you bad habits.

Worse, learning by doing adds a kind of pressure to the project in the form of an external goal to satisfy. If you set out to learn, do a bunch of things, and learn about them... well, mission accomplished. But if you set out to learn by doing, you have the complication of whether the project worked or not. After all, your project might have been successful in teaching you things, but if it also had the goal of also doing something useful, you can't really feel like it succeeded if it doesn't do that thing.

I've noticed this issue in prototypes sometimes, and it's what led me to start thinking about the idea triangle and tire kickers and so on. I would often give in to the temptation of trying to learn something and achieve something at the same time. After all, that's twice as good! But you pay for it by pulled in two directions. You're trying to serve two masters. One of them wants the best for you. The other wants what's best for the project.