In this previous article, I introduced chunking as a concept in learning. Next, I’d like to demonstrate applying chunking in the context of software development. Learn I wanted to see if this process could be streamlined even further, since a lot of the time in the workplace, we don’t have the luxury of a pre-defined syllabus.
If you recall, we got introduced to the idea of working memory having the 4 working areas. As we intently focus to understand new concepts, these 4 areas get used. As we slow down, and reflect, these concepts get knitted together, or consolidated as we see on the right.
Illustration 1: How chunks are formed in long term memory
A recap of teacher vs student chunking
If you remember from the previous article, I explained how the teacher had one view of the world. Namely all of their experience in their head, as these chunks. Conversely the student (you) had a much more sparse view of the world. Everything are seperate pieces in working memory, as you learn something for the first time.
In the day job, developers (students) more often have resources (website, books, tutorials) than teachers. We’re self-managing after all. So I’d like to show how we can be both teacher and student at the same time. Applying chunking to software development an be done by:
- ‘Playing teacher’ to create our syllabus.
- ‘Playing student’ to retain our syllabus.
- ‘Playing developer’ to work out where the effiecines lay on a case by case basis.
Applying chunking to software development – a scenario
I’ll cover a scenario that you often encounter in the workplace. Let’s say some work is coming up with a technology you’re not familiar with – and you’re under time pressure. If we can skim (but still retain) the fundamentals of a subject, we’re covered either way:
- Requirement ends up not materialising, or gets assigned to someone else? You’ve still learnt something for the future that you’re highly like to use in a different context.
- If it does end being you doing the work though, you’ve given yourself a head start, and can start diving in a bit deeper straight away.
Scenario: the technology you’re expected to magically know
Giving an example from a previous role, the team I was on is writing some integration software between us and an external vendor. The details aren’t especially important, other than:
- What we have will have to run in a way that can be scaled out.
- At some point there is the possibility of a race condition.
In other words, it will have to use whatever mechanisms there are for multi-threaded programming.
In this scenario, I had a few problems to deal with:
- I hadn’t done concurrent programming, in a long, long time — I hadn’t really needed to.
- Due to the nature of agile projects, it was likely, but not certain that we might pick up this requirement soon.
- Ideally an agile team won’t have just one person who can pick up the work.
- It’s going to take me time to learn what I need if it ends up being me picking it up.
I’d apply chunking to software development work with the steps I’m about to outline.
Step 1: Gather your materials
Since I knew I’d need to get up to speed on Threading and Concurrency, and I knew there would be coherent, structured training online, I could set up a system to apply the chunking techniques. All you need is the following:
- The material itself (https://docs.oracle.com/javase/tutorial/essential/concurrency in this case)
- A flashcard system (I used cram.com here, you could use Anki as it’s free.)
- A pomodoro timer
- An hour of your time.
That’s it. Once you have these tools you can build your ‘first pass’ material.
Step 2: Search for summaries, start for questions
One the timer had started, I scanned through the page on the tutorial. For each page, I formed a question for my flashcards. I created a high level flashcard with a question for each slide. The excellent “Make it Stick”(4) has a great expression when recounting a case study for a military school in the US. When going through material ‘Start for questions, read for answers’ — in other words, what is the point of reading this slide?
Since this is an official training trail, you can be pretty sure that the pages are structured in a way that will give you at least one ‘takeaway’ per page.
When the material is a textbook you can do the same with reading the start of sections and the final summary in the chapter as a first pass.
Step 3: Make your test question specific enough to push you
As an example, the very first page states:
“The Java platform is designed from the ground up to support concurrent programming, with basic concurrency support in the Java programming language and the Java class libraries. Since version 5.0, the Java platform has also included high-level concurrency APIs”
My first flashcard in this collection then became — ‘name 3 ways Java supports concurrency’.
I continued like this for 2 pomodoros, (with breaks) taking me to an hour spent overall. By then I built out a set of flashcards with specific questions on high-level concepts.
Step 4: Set your reminders
Once I had this set of high level questions, I reviewed it the next morning and set up my ’spaced reminders’ using a GTD system (see my other article here for more on that). Using www.cram.com, I would test myself on the flashcards I had written.
Even during the ‘first recall’ the next morning, my brain was already ticking on how these high level pointers would fit into what I was doing at work.
Step 5: Determine any further investment
This part has to be a judgement call for you and your workload. In my case, I extended my learning a little further ( a few more hours of coding with learning tests) to get a bit more in-depth as I suspected I might need the knowledge for my job. As an exercise, you might like to look at the concurrency trail with a pomodoro timer and see if you can spot which of my flashcards are obviously from a ‘first scan’.
Applying chunking to software development projects effectively is a case of knowing when you have grasped enough to get started. At that point the coding can take over!
Developing ‘just enough’ expertise
You might see from the slides given that there isn’t anything in there that would be specific to my job. Apart from the obvious restriction of not putting confidential work information into the public domain, I didn’t want to pollute these flashcards with specifics. It only has high level, generic concurrency concepts in there.
The number one reason for this is because of the nature of Agile projects. Time spent recording specifics into flashcards is time taken away from the development of working solutions. That’s certainly not to say that I didn’t use ‘learning tests’ to try and find out how an API worked for our project, far from it.
It’s just that at some point we actually have to try and build something ‘for real’, and I felt once we left the ground of fundamentals, then the experience would come from building and iterating the software rather than adding to my flashcards.
Likewise, if something changed about the implementation as new information was discovered during the project, recording flashcards for that might be wasted effort.
My ‘acid test’ for whether something should go onto a flashcard was:
‘Can I say, with what I know now, that I’ll definitively re-use this concept?’ — if no, it didn’t make the cut.
Conclusion
I found time boxing an invaluable technique to focus on getting the gist before diving any deeper into a subject. I used 25 minute blocks to get a ‘first scan’, but as a bare minimum you need to be building questions from each section.
On subsequent tests of the material, I adjusted the questions to more specific and probing, reflecting that I’d had more context now.
However the biggest win was with what I discarded — the biggest gain for me was learning how to quickly gain an overview and then zero in on specifics in my day to day job. I’ll always have the flashcards and learning tests for re-use, but I didn’t spend time on implementation details I’ll never use again — this freed me up for ‘direction changing’ on the project.
Your experiences of this approach
I’d really like to hear from you next, in the comments below, or you can contact me. It would be great if you could respond to this article with how you got on with this approach, or what did and didn’t work for you. Likewise if you have any further questions on this, please respond in the comments section too.
Citations and References
1Vonge Corry, Aino. “A comment on how we learn” https://www.Youtube.Com/Watch?V=Ozyipg-Ox8y. 2017. Video.
2 https://www.coursera.org/learn/learning-how-to-learn/lecture/LurUJ/2-2-what-is-a-chunk
3 Octopus of attention and diffuse tentacles, images, Kevin Mendez, 2014
4 Brown, Peter C, Roedinger III, Henry L, McDaniel, Mark A. “Tips for Teachers.” Make it Stick. Cambridge, Massaechusetts, London England: The Belknap Press of Harvard Press, 2014. Pages 234–235. Print.