But everything you add to your product dilutes everything else. It becomes harder to use. It becomes more expensive to support. And chasing individual features and one-off fixes can unfortunately shield you from coming up with even simpler approaches that solve this problem and seven others at the same time.
That’s not to say you should ignore customer feedback, or ignore your sales channel, or anything of the sort. It just means you deeply consider every little product change you make. It means you only make these changes if it aligns with your goal and will make your users happier in the long-term. It means you’re proactive rather than reactive.
Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
From Rob Pike’s 5 Rules of Programming.
Mr. Einstein, writing to the highly esteemed Mrs. Curie:
P.S. I have determined the statistical law of motion of the diatomic molecule in Planck’s radiation field by means of a comical witticism, naturally under the constraint that the structure’s motion follows the laws of standard mechanics. My hope that this law is valid in reality is very small, though.
From Eugene Ferguson’s Engineering and the Mind’s Eye:
The conversion of an idea to an artifact, which engages both the designer and the maker, is a complex and subtle process that will always be far closer to art than to science.
Quoted by Glenn Vanderburg in his great talk on why software development is an engineering discipline.
I have the hardest time remembering what I’ve read and when I’ve read it. I’ve started several books over the past few months, but here are the ones I’ve enjoyed enough to finish: