Daniel Lemire wrote a post recently comparing one of Paul Graham’s essays on startups with the process of doing research.
It reminded me of a book I read recently, and an observation I made on it. The book was 101 things I learned in architecture school, and the observation was that half the advice applied just as well to software development as it did to architecture. I find this is often true: At the general level, good advice is very portable.
Here are some excerpts:
61. Less is more
Minimalism is not something that’s hard to find in software design (or at least software design as we want it to be instead of the endless feeping creaturism that it often turns out as). Particularly epitomized by the Unix philosophy of “Do one thing, and do it well”.
62. Less is a bore
On the other hand, there’s a reason we’re not all still living in the command line…
32. The most effective, most creative problem solvers engage in a process of meta-thinking, or “thinking about the thinking.”
Good advice anywhere, but particularly so in software development where there’s so much capability for abstraction.
81. Properly gaining control of the design process tends to feel like one is losing control of the design process
There’s a good chunk of explanatory text in the book about this one, which I’m not going to reproduce here. In short, this is about not becoming prematurely wedded to ideas and embracing the uncertainty needed for finding the right solution.
17. The more specific a design idea is, the greater its appeal is likely to be
Tools for solving everyone’s problems tend to be tools for solving no one’s problem.
90. Roll your drawings for transport or storage with the image side facing out
Ok. Maybe not this one…