This page looks best with JavaScript enabled

Study: Knowledge Persistence with Use Cases

 ·  β˜• 4 min read  ·  ✍️ Brett Johnson

Building use cases to learn new products allows for new knowledge to be applied and persist much longer.

Learning new topics and maintaining that knowledge is a skill. By dedicating time to understanding a range to topics, you start to understand how to learn and become more efficient.

Watching videos, reading, rewriting and review are great ways to get knowledge in. But, unless you apply context and apply learning the knowledge will slip away quickly. Interactive labs help with this however, they only provide a narrow focus. By thinking of a use case and achieving that goal, you cover a broad range of product feature and pitfalls.

In this article, we will go through the value of having a unique use case. The examples I will be using are primarily around Chef, but the subject is not tied to this product.

Learn absolute foundations

Technology without a use case or problem to solve has no value. Therefore, to get value out of learning you need to solve a problem. In learning phases use cases can be very simple and provide foundational skills. How far you want to take this is entirely up to you and your circumstances.

When thinking of a use case start simple and ask yourself these questions:

  • What is the function of the product at a high level?
  • What is the most fundamental task?
  • Can I do that without referencing?
  • Can I do that to β€˜best practice’;?
  • Can I do that in a secure manner?

Using Chef as an example, a very simple function is to ensure a file exists and has not changed. This is a foundational task as the process will reference the desired state and enforce that state.

Is this a task I can complete from start to finish with having to reference guides? If you can do most of it, start moving more files, or folders. This will expand the way you think of the task and help maintain the knowledge.

Best practice and security overlap a little with this sort of task. A best practice in your circumstance could be to use attributes, either in a file or data bag. Can you do this confidently?

If there are credentials in use, are you retrieving and storing these in a secure manner?

Once you have some fundamentals, it’;s time to jump in the deep end. Find a decent task and start breaking it down into smaller pieces. At the start this seems straight forward, but as you continue there you will uncover many additional small steps and challenges. These pieces are what can really help the learning stick.

Build a use case

Think of a use case that the product can solve but is not too complex. You can scale back the problem you’;re trying to solve or pick a smaller piece of that problem. Ideally, you need a use case that will be a challenge.

You will be googling a lot trying to solve the problem and changing the method often, this is a good thing. Not only are you going to find what works, you will learn what doesn’;t while building context.

With Chef, I chose this because I have a need to create a Windows test lab in AWS that can be created and destroyed constantly. To achieve this, I have had to learn many new functions of Chef. Many options lead to dead ends or were redone because a better way was found.

While working through the use cases don’;t forget about best practices and security. Sure, get the current section to work but when it’;s working go back and fix weak points and secure it.

As you progress through your project or after completing a number of small projects, take the time to go back and look at where you started. It’;s likely you’;ll find that you have found new and better ways to approach the original problems.


First, understand the problem that lead you to choose a product to learn. From there, build a use case from that problem or part of it.

Solve the problem to a production ready standard and ensure that you understand what you did and why you did it. This builds good habits and context which enforces your learning.

I have previously written about the importance of context. That is available here.

Share on

Brett Johnson
Brett Johnson
Automator of things