Docendo discimus and Retroactive Interference
By teaching, we learn and when we learn, we sometimes forget.
docendo discimus
This Latin phrase translates to “by teaching, we learn.” Thanks to Chandra Guntur for teaching this phrase to me, a few days before a talk I gave at QCon New York in 2018. I have used this phrase so many times over the last six years, that I included it in a new category in the Desktop Don Reference with the title of “Communication” .
I was reminded about how much I love teaching, by my former colleague Bhavana Hindupur, in a LinkedIn post yesterday. Thank you, Bhavana! I thought I would take some time to share a lesson I learned while teaching the Eclipse Collections Katas over the years.
I have taught the Eclipse Collections Katas since 2007. In the early days, there was one kata — The Company Kata. This kata was originally developed by John Tobin and later evolved into training materials developed by Craig Motlin. We would teach the Company Kata in Goldman Sachs as an eight hour training class for Java developers. In 2014, I would write a two part series of InfoQ articles with the title “GS Collections by Example”. In Part 2, I would introduce a set of examples that Nikhil Nanivadekar would later convert into the Pet Kata. We would start teaching the Pet Kata as a four hour class. Spending eight hours on intense focused learning is exhausting and hard to fit in some folks schedules. Four hours proved more manageable.
There were many things I have learned while teaching these katas over the past 17 years. I was reminded of one thing I learned while explaining a “fused” Eclipse Collections method in a tweet earlier today. One thing I saw every time I taught the Company Kata was how new learning can sometimes obscure old knowledge.
In exercise two of the Company Kata, developers would learn how to use anySatisfy with a Predicate to determine if any Customers lived in “London”. In exercise four of the Company kata, they would need to find a way of finding a Supplier who supplies a “sandwich toaster”. After a bit of a struggle, most of the developers would figure out how to use anySatisfy to solve the problem. The better solution is to use contains. The method named contains is part of the standard Java Collection protocol. Unfortunately, in the exercise, the data structure that developers would need use contains on is not a Collection, it is an array. An array in Java has no behavior. Developers had learned in the class how to use ArrayIterate
When I would explain my solutions to the developers in the class, I would explain that contains can be implemented in terms of anySatisfy, using an “equals” Predicate. The developers had good intuition, but in the midst of learning new things (anySatisfy), had forgotten about old things they knew (contains).
Retroactive Interference
Chandra taught me the Psychology term for this phenomenon today. He said it is called “retroactive inhibition/interference”.
Most Java developers will learn Java Stream anyMatch after learning Collection contains first. I wouldn’t be surprised if some Java developers are using anyMatch instead of contains to solve some problems. This would be unfortunate, as contains is optimized for Set and Bag.
We have to learn and remember a lot as developers. The more we practice, the more we can remember. It is helpful to learn basic patterns like anySatisfy, and then fused patterns like contains (anySatisfy + Equals Predicate).
The tweet I mentioned earlier in this blog that I shared today described another fused pattern, which combines map + anyMatch + Equals Predicate. When you see anyMatch + Equals Predicate, you should now immediately think “contains!”. The rest of the info on the other fused method is in the “Fusing methods for productivity” blog below.
Enjoy! 🙏
I am the creator of and committer for the Eclipse Collections OSS project, which is managed at the Eclipse Foundation. Eclipse Collections is open for contributions.
