[T]he IE6 era forced us to think about what we web developers really wanted. We had to define and defend every single feature we requested … and set priorities.
Two links hardly prove a thing, and there are plenty of people who disagree. But there’s been a recent trend questioning the web we’ve created (c.f. The Verge’s Web Sucks) and I tend to side with the questioners.
Rather than offer users persuasive reasons to upgrade software, vendors insist we look on upgrading as our moral duty. The idea that something might work fine the way it is has no place in tech culture.
From his talk, “Web Design: The First 100 Years” – an insightful take on how the tyranny of the new has shaped web and tech culture.
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: