Maximise your RoI
I setup an account on bitbucket, so that I could check in any tests that I wrote. Combined with cram being available online and offline (on my tablet and phone), I had reference material that I could refer to anytime, anywhere.
This was huge bang for buck. To give an example, this month I’d written learning tests against the BigDecimal API. At work, when I was under time pressure to see why a unit test failed, I simply pulled down my learning test repo and found a scenario matching what I needed. As I was scanning the code, I got a refresher on the API ‘for free’!
As the ‘Learning How To Learn’ Course has also mentioned(5), each time you recall information in new scenarios, the information and memories are strengthened and enriched, so you’re getting even value out of this approach by having a digital system you can call up.
Final words and findings
I’ve written a more extensive article on how my system was setup, and will link to it to here for anyone interested in specifics in due course.
For now I’d like to re-iterate a few key points:
- It’s important to decide which subjects warrant this investment because that’s exactly what it is. I’d lean towards this approach for learning the fundamentals of a subject because they are points that are good ‘bang for buck’. You will get the benefits of long term recall for information that will be applied again and again,in a variety of contexts.
- I’m not sure specific implementations of subject matter need to be committed long term — I don’t think the ‘lifespan’ of the is worth slowing you down.
- To give an example, I’d written learning tests about reflection because a Framework like Spring makes extensive use of it, but I wouldn’t write learning tests for developing Spring Web Project at work. In these cases my learning would be from actually developing the project! (And of course, I’d write unit tests for any development I did anyway)
- I was shocked to see how many times an API would surprise me by failing my tests and this nicely demonstrated two points from the book, ‘you learn far more from failing’ and ‘you learn more when you try and generate the answers for yourself’.
- Where you don’t have a concrete use case right now for a fundamental concept, this is where the learning tests really come into its own. You have a set of *proven* reference material with no need to reinterpret documentation each time.
Your feedback
I’d love to hear from you now, in the comments section. Did you like the article? Any pointers for me to improve what I deliver to you? Any success with this approach? Have you hit any stumbling blocks?
It would be great to know what you think.
Resources
Flashcards
As an example of a set of flashcards, I’ve linked to some flashcards I made on reflection, date/times and collections .
Bitbucket project of learning tests
I included a set of resources here that I’ve been using to learn APIs, you’re welcome to use for yourself, but if you re-blog, please link back to this article. Note that some of the tests (collections and concurrency) are still work in progress to get fixed comprehensively — I’ve left them in here deliberately as a reminder that I still haven’t mastered these points.
Citations
- Brown, Peter C, Roediger III, Henry L, McDaniel, Mark A. “Reflection Is a Form of Practice.” Make it Stick. Cambridge, Massaechusetts, London England: The Belknap Press of Harvard Press, 2014. Pages 26–27. Print.
- https://www.coursera.org/learn/learning-how-to-learn/lecture/BuFzf/illusions-of-competence
- Brown, Peter C, Roediger III, Henry L, McDaniel, Mark A. “Testing: Dipstick vs Learning Tool.” Make it Stick. Cambridge, Massaechusetts, London England: The Belknap Press of Harvard Press, 2014. Pages 18–19. Print.
- Martin, Robert C, “Exploring Boundaries” Clean Code: a handbook of agile software craftsmanship. Stoughton, Massachusetts. Pearson Education. Pages 116–118. Print.
- Brown, Peter C, Roediger III, Henry L, McDaniel, Mark A. “The Takeaway” Make it Stick. Cambridge, Massaechusetts, London England: The Belknap Press of Harvard Press, 2-014. Pages 43–44. Print.