I learned from physics that it is often best not to rush in to solve a problem. The time you invest in really understanding a problem is typically given to you back several-fold:
- It simplifies the problem at hand;
- It creates new learning in your mind, which will make subsequent similar problems easier to tackle.
Again, the representation you choose matters, but not quite in the same way that it matters in weekly physics assignments. You're not trying to knock a particular ball out of the park. In a software project you're typically trying to design pieces that will interact together and that you will be using to build larger pieces still.
Of courses the pieces have to "work", but great design means that they have a special quality beyond just being correct: they're easy to understand and use. And they will still be easy to understand in use six months from now, when you return to that code after having been busy with something else. Or when someone else dives into your code.
An operating principle here is to make everything as simple as possible, but not simpler. It usually takes work to get there, but it is amply rewarded in the long run.
To summarize: doing physics and computer science, I learned about the value of making the effort to make things simple. (as Mark Pilgrim said: "A lot of effort went into making this effortless")
Now, the great thing about it is that lessons learned about thinking are applicable wherever there is thinking involved, which is a pretty wide domain of applicability when you think about it. In a future post I want to explore how these principles influence the impact and diffusion of ideas, whether they be theories, methodologies, memes, or musical themes.