“Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It’s time for software developers to take up the mantle of responsibility for what they produce. Testing alone isn’t sufficient, but it is necessary.”
~ Neal Ford (as seen on this tweet)
This Wikipedia page on continuous integration is actually a good resource for computer programming best practices.
twobithistory.org has a nice story about Lisp titled, How Lisp became God’s own programming language. That page links to Paul Graham’s old Beating the averages post where he shares this Eric Raymond quote: “Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot.”
A friend of mine is an honest reviewer of apps. When I asked her to use the AAA iOS app while we were driving back from Florida, she said, “OMG, please don’t make me use that piece of crap again.”
From this AirBnB article about using React Native: “JavaScript is an untyped language. The lack of type safety was both difficult to scale and became a point of contention for mobile engineers used to typed languages who may have otherwise been interested in learning React Native ... A side-effect of JavaScript being untyped is that refactoring was extremely difficult and error-prone.”
The 90/90 Rule: “The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.”
~ Tom Cargill
Here’s An Illustrated Proof of the CAP Theorem, if you’re into things like consistency, availability, partition tolerance, and distributed systems.
Based on his current work in developing Rust, Aaron Turon has a couple of good blog posts on developing/leading open source projects titled, listening and trust, part1, and listening and trust, part 2.
I just came across a couple more null values out in the wild, this time on the espn.com website.
A video I want to watch: Why writing correct software is hard, and why math (alone) won’t help us.
For the first time in many years I just came across Kent Beck’s Four Rules of Software Design:
There are wording variations on those rules, but I got those specific words from this Martin Fowler post. As he notes, “The rules are in priority order, so ‘passes the tests’ takes priority over ‘reveals intention.’”
For more information on Kent Beck’s Four Rules of Software Design, see that link, or this link to the original rules on c2.com.
I haven’t worked with JavaScript much in the last few years, and I just learned about this cool console.table output-logging technique, which I just saw on this website, which has several other good JavaScript debugging techniques.
When asked, “What is the value of learning lambda calculus,” Gary Bernhardt replied, “My favorite reason to learn a bit about the lambda calculus: it shows us 1) how simple computation is (at first it seems too simple to compute anything ‘real’); and 2) all of our programming complexity is invented by us (for reasons both good and bad).”
I haven’t watched this video from Ruby Conf 2012 by Jim Weirich yet, but if you’re interested in learning about functional programming only for the sake of learning, here’s the description: “One of the deepest mysteries in the functional programming world is the Y-Combinator. Many have heard of it, but few have mastered its mysteries. Although fairly useless in real world software, understanding how the Y-Combinator works and why it is important gives the student an important insight into the nature of functional programming.”
A long time ago — 2005, to be exact — I read this article named Making wrong code look wrong, and it was a big influence on me. These days I don’t know how many people use variable naming conventions, but when working on web applications I still like the “us” (unsafe) and “s” (safe) convention for handling user input. As Joel Spolsky discusses in that article, that convention has a good way of making wrong software code look wrong.
I can’t say I understand it all, but Alan Kay wrote an article on Quora titled, Why is FP seen as the opposite as OOP rather than an addition to it?
“Many functions in Lisp are list-eaters.”
From the book, Land of Lisp
(The same can be said about pure functions in Scala.)
“Talk is cheap. Show me the code.”
~ Linus Torvalds
Last night I was reading the classic old book, The Pragmatic Programmer, and came across this definition of DRY, an acronym that stands for Don’t Repeat Yourself:
“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”
That’s well stated, especially after a recent experience in which I found some code where I created an “Add Widget” dialog in a different way than I created its related “Edit Widget” dialog. I created the main pane of the dialog the same way, but I managed the details of the two dialogs that contained that pane differently, and I realized what I had done when I decided to make the dialog resizable. When I discovered what I had done, I refactored the code so both the Add and Edit dialogs were created by a single method.
Whenever I see a programming error, I try to imagine the circumstances behind it.
