Step 1: Work out my actual goal
In this case, I want to know enough about DynamoDB to be able to contribute as a senior developer. Referring back to these expert traits, I’d wants to:
|Expert Trait||Example with my use case|
|Grasp the fundamentals.||Understand the building blocks of DynamoDB (beyond the ‘exam trivia’ I already have).|
|Develop complex knowledge structures in my memory.||Have the ideas behind the major concepts drilled in memory, so I can apply combinations of these – ‘slicing and dicing’ as it were.|
|Reflect on how I’m going.||Review how what I’m learning is improving my understanding of the conversations I’m part of. Are they making more sense now?|
Leading to my actual goal.
- To understand the different components/concepts of DynamoDB.
- To understand when to use each concept by understanding the differences between them.
- My first measure of success is being able to use constructs without excessive use of documentation – i.e. from memory.
- My second measure of success is using this new learning and my existing experience to recommend courses of action to the team, earning my keep as a senior developer.
Step 2 : Creating my initial training for the fundamentals
The first step is to look at the course syllabus and see what is even covered. This gives me an idea of “what the experts think I should know”. Here’s a screen grab of some of the content.
However as well as finding my gaps in the first place, I need to work out when those gaps are filled. I don’t have any exam to grade me after all. And just because I remember the course content, doesn’t mean that’s actually going to be any use to me in the day job. So I need to fix the disconnect between the theory and what I need specifically. In other words, I need to work out what my test plan should be for a ‘real world’ application.
Step 3 – build complex structures
I have a two-pronged approach to start building these.
Build chunks from the course notes.
Labs are hands on, but you need to get the big picture. So as I followed the course, I kept reflecting on the high level ideas. Here’s a simple word document of DynamoDB querying. I kept synthesising the big ideas as I went through the module. How did one thing flow to another? I re-organised my content as I learned more. I simplified details that were irrelevant.
Drilled the knowledge with hands-on training
I wanted to focus on high level ideas in my word docs, because common sense would dictate that the labs would be more specifics. Half the battle was already won this way – at least this was my hope. By the time I came to do the lab, I had a good idea of the principles. Then it would just be a case of using the CLI and getting enough exposure for the ‘muscle memory’ to sink in.
Step 4 – reflect on how I’m going DURING the course.
I didn’t do this to an extensive/overly formal level. It was more a case of “do my notes cover the important parts of the lab, and did the lab feature the important parts of my notes?” In this case, I was reflecting in the success of my identifying the big picture concepts. If the expert (the course presenter) had put something in the lab, it was obviously a key point. If I missed it, that was a blind spot of mine that I needed to cover.
My feedback loop at this stage was effectively:
- Reviewing my ‘chunked notes’ against the lab points – updating/simplifying my notes if needed.
- Trying extra experiments with the CLI if my notes contained more detail than the lab.
The far more important reflection would come after the course.
Step 5 – Review how effective my learning was AFTER the course
Fundamentally I will need to be able to answer:
- How well can I recall the info on demand?
- How relevant is what I learned to my day job?
If I want to contribute to work conversations, these core concepts need to be ‘drilled’ in my memory. Imagine me stopping a meeting every 30 seconds to check my understanding of indexes or tables, and you get the idea. Similarly, if I want to troubleshoot a problem, the CLI operations need to be drilled in memory too. If I can’t do that, that’s a blind spot that as a software developer I want to fix.
As for the relevance of your learning, this is where your planning will pay off.
Have I reached my goal?
- Do I now understand the different components/concepts of DynamoDB?
- Do I understand when to use each concept by understanding the differences between them?
- Can I recalled concepts/constructs. from memory – so I can follow conversations?
- Using my recalled concepts/constructs, can I leverage my existing experience and provide advice to the team?
For contributing to new conversations, I will refer to the above bullet points to see how effective my training was.
For development, and troubleshooting, if I will consider my learning plan a success if I can use the CLI largely from memory. If I’m struggling to even work out which CLI operation to use for a scenario, that’s a sign my original learning was ineffective. If I’m only struggling on CLI syntax, I’ll refer to the help files, get what I need done and consider it a success.
For historic conversations, the remote working world gives us some new tools to test the gaps. Slack conversations, recorded Microsoft Teams meetings, Wiki documents. All of these are filled with DynamoDB terms that might previously have baffled me – I could search these fairly easily were I so inclined. Have terms suddenly started making sense? If yes, then my training plan worked pretty well.
What will I do differently next time?
It will need thinking over when I come to review the process. Did I go overboard for my work situation? Did I miss key areas that would have sped me up? Did I under-plan? Did the plan effectively give me a link between the generic (tutorials) and specifics?
Conclusion – is this effort worth it?
Well that’s a question for yourself. In my mind, most people don’t move beyond – “do I know this stuff?”. They just do the questions, do the tutorial, pass the test. However in some situations, I think it’s worth investing in more than just the outcome itself. If you can refine your process as as well, you might come up with more effective ways of learning content in future. Also, finding your weaknesses within each software developer discipline might require different tactics. But it’s an investment in your career.
As ever, please feel free to contact me with any further questions, or use the comments section below.