Skip directly to search

Skip directly to content

 

8 Tips for Sharing Technical Knowledge – Part 1

 
 

Software Engineering | Laurentiu Spilca |
12 November 2020

Helping others upskill has always been something I’ve considered essential. When you know something, you’ll make it ten times more valuable by sharing it with ten people! But sharing knowledge is not easy, especially concerning technical subjects. Do you want to help your community through sharing specific knowledge, but you don’t know where to start? Are you afraid that you won’t do a great job? Have you ever tried to convey a technical subject but failed? In this article, I’ll discuss some important tips you should consider when sharing knowledge and the most common mistakes you need to avoid.

1. CREATE A MENTAL MODEL

The first thing I’d like to mention is the mental model. The lack of a mental model is one of the most common causes of failure in knowledge sharing. Helping your audience build their mental model consists of defining a clear path to learn the subject you deliver. A mental model is an explanation of someone’s thought process about how something works in the real world. Mental models help to shape behaviour and set an approach to solving problems and doing tasks. It doesn’t matter if you deliver a presentation, a workshop, or write a book or an article – you need to help your audience build their mental model. You can find a detailed description of mental models with additional reading resources here. But what precisely does it mean to create a path for those with whom you share knowledge?

When starting with knowledge sharing, you might be tempted to only tell your audience how that specific subject you describe works. However, you should always tell your audience a few things beyond that. The following aspects are part of the mental model:

  • Why should your audience care about what you deliver, and why should they learn it? Tell your audience why the specific subject is valuable and what they’ll be able to do after mastering it. In order to be motivated to learn something, one must first understand its value.
  • How will you deliver the knowledge? Tell your audience which steps you’ll follow to help them understand the topic. Are you going to tell them a story, discuss a visual, or will you be working on a code example? Your audience needs to know what to expect.
  • If you’ve already mentioned certain aspects that your audience should know, it’s good to remind them that these are a prerequisite, that you’ve discussed the subject before, and where they can find it.
  • If you refer to a subject you won’t detail later in your training or article, offer your audience other resources to learn more about that topic if they wish.

Let’s look at an example to illustrate this: Say you want to teach someone how to declare a variable in Java. First, we’ll consider the case without using a mental model, in which you might say something like this:

“To declare a variable in Java, you first need to know the type of value you’ll assign to the variable. Then you choose a syntactically valid name. The name of the variable follows its type, and the instruction concludes with a semicolon.”

While the above paragraph might look clear if you already know what a variable is and how to declare it, for a beginner, a lot of details are missing:

  • What is a variable? Maybe you’ve discussed it previously, but you should remind your audience about it and tell them where to find that information.
  • Why should your audience know how to declare the variable? What value is gained by spending their time learning this subject, and how will it be useful afterwards?
  • What does “syntactically valid” mean? Have you covered this subject already, or are you going to do so in the next lesson? You should be explicit about terms you’re using and where you’ve covered them.

Additionally, you need to consider the knowledge level of your audience. How much into detail should you go? You don’t want to bore them if they already have a clear idea of what you teach. If your audience knows the general subject, but you wish to introduce something more specific, be clear with your description and get straight to the point. However, assessing if your audience already understands certain topics is always tricky. Suppose you have a group of twenty people. Will they have equal knowledge and understanding of a topic? Most probably not, so you’ll have to find the proper equilibrium, ensuring that everybody learns what you deliver without those with more advanced knowledge getting bored.  

Here is an example of how you could present the same topic using a mental model: 

Next, we’ll examine how to declare a variable. As we’ve already discussed in the previous lesson, a variable is a place in memory where we store values that we’re going to use. You need to know what variables are and how to define them because in most cases you won’t be able to implement an algorithm if you don’t temporarily store part of the data you process. The easiest way to store this data is by using variables. The first step is to know what kind of value you’ll store in a variable. Say you want to store integer values like 10 or 15. Then your variable type will be ‘int’. You’ll choose the type from those we discussed earlier in this lesson. Then you’ll choose a name for your variable. The variable name needs to follow some syntax rules, which we’ll discuss later in this lesson. The name of the variable follows its type, and the instruction concludes with a semicolon.” 

Certainly, the second approach of delivering the same information is longer. Adding the mental model can more than double the content, but it makes the difference between “some understand what you deliver” and “almost everyone understands what you deliver”. Let’s dissect the second approach and discuss why the additions are essential. 

Next” 

Observe that I started with making the audience aware of what comes next. Always refer to what you’re going to teach before actually teaching it. 

As we’ve already discussed in the previous lesson” 

If you use a notion that you discussed before, refer to it again and remind the audience where they’ve learned it. For example:

  • “earlier in this lesson”
  • “in lesson 2”
  • “earlier in this presentation” 
  • “at the beginning of my presentation”
  • “in section 2.2 of this article”
  • “in chapter 2 of this book”

This way, your audience will remember the notion more easily, and you give them the opportunity to take note and review that subject later. 

a variable is” 

Give a short definition to remind your audience about a notion you’ve already discussed. 

You need to know what variables are” 

Give your audience a motivation and clarify the value of learning about that specific subject. 

which we’ll discuss later in this lesson” 

Always let your audience know if you’ll further discuss a notion later. If you only discuss it briefly in your course or presentation, it’s a good practice to share other, more detailed resources on that topic like book titles and chapters as well as links to articles, video tutorials, or presentations. 

2. USE AT LEAST TWO WAYS TO PRESENT A TOPIC

People delivering knowledge often make the mistake of using only one way to describe a topic. You’ll find this issue in many articles around the web, be it on StackOverflow, Medium, Baeldung, or other well-known sources. The authors offer valuable information, but they cover their subject too quickly and use only one way to present the subject. For many people, especially those with less experience in the field, this approach can impede understanding. 

Because people differ in how they absorb information, you should use two or three different ways to ensure comprehension. Some of us learn best when reading or listening to a description of a technical topic, some benefit from a visual presentation, and still others prefer to get an analogy. Here are different ways to present a topic:

  • Written or spoken description – Describe in words the topic the way you understand it.
  • Written or spoken analogy – Give an analogy of the topic, for example, by comparing it with a subject from a non-technical domain. In some cases, you could also tell a joke.
  • Visual representation – Draw a diagram or show a graphic to help your audience understand the subject.
  • Visual analogy – Use a cartoon, picture, or meme and compare it to the technical topic you’re teaching.
  • Examples and exceptions – Tell your audience when it is beneficial to use the approach, technique, or technology you describe, and also tell them when they shouldn’t use it.
  • Story from your own or others’ experience – Stories are great, and you can use them to illustrate the impact of a specific topic. In most cases, we use stories to show the importance of the subject we teach.
  • Source code – Where applicable, you can demonstrate a technical subject by discussing a source code example directly.

In part 2, I will present six more tips for sharing technical knowledge, including the value of examples and feedback as well as the pitfalls of overestimating your audience and how to avoid learning gaps.

Laurentiu Spilca

Development Consultant

Laurentiu is a dedicated development lead and trainer who leads and consults on multiple projects from various locations in Europe. With 10+ years of experience, he believes it’s essential to deliver high-quality software and to share knowledge and help others to upskill. This belief has driven him to design and teach courses on Java technologies. When he isn’t teaching or writing – his new book is Spring Security in Action – Laurentiu enjoys riding his motorbike, playing the guitar and the piano, and exploring new destinations.

 

Related Articles

  • 12 November 2020

    8 Tips for Sharing Technical Knowledge – Part 1

  • 30 October 2020

    API Management

  • 22 September 2020

    Distributed Agile – Closing the Gap Between the Product Owner and the Team – Part 2

  • 25 August 2020

    Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 2

  • 18 August 2020

    Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 1

  • 08 July 2020

    A Virtual Hackathon Together with Microsoft

  • 30 June 2020

    Distributed SAFe PI Planning

  • 09 June 2020

    The Twisted Concept of Securing Kubernetes Clusters – Part 2

Most Popular Articles

8 Tips for Sharing Technical Knowledge – Part 1
 

Software Engineering | Laurentiu Spilca | 12 November 2020

8 Tips for Sharing Technical Knowledge – Part 1

API Management
 

Architecture | Gareth Badenhorst | 30 October 2020

API Management

Distributed Agile – Closing the Gap Between the Product Owner and the Team – Part 2
 

Agile | Thomas Behrens | 22 September 2020

Distributed Agile – Closing the Gap Between the Product Owner and the Team – Part 2

Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 2
 

Architecture | Radu Vunvulea | 25 August 2020

Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 2

Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 1
 

Architecture | Radu Vunvulea | 18 August 2020

Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 1

A Virtual Hackathon Together with Microsoft
 

Innovation | Radu Orghidan | 08 July 2020

A Virtual Hackathon Together with Microsoft

Distributed SAFe PI Planning
 

Agile | Florin Manolescu | 30 June 2020

Distributed SAFe PI Planning

The Twisted Concept of Securing Kubernetes Clusters – Part 2
 

Architecture | Vlad Calmic | 09 June 2020

The Twisted Concept of Securing Kubernetes Clusters – Part 2

Performance and security testing shifting left
 

Testing | Alex Gatu | 15 May 2020

Performance and security testing shifting left

 

Archive

  • 12 November 2020

    8 Tips for Sharing Technical Knowledge – Part 1

  • 30 October 2020

    API Management

  • 22 September 2020

    Distributed Agile – Closing the Gap Between the Product Owner and the Team – Part 2

  • 25 August 2020

    Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 2

  • 18 August 2020

    Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 1

  • 08 July 2020

    A Virtual Hackathon Together with Microsoft

  • 30 June 2020

    Distributed SAFe PI Planning

  • 09 June 2020

    The Twisted Concept of Securing Kubernetes Clusters – Part 2

  • 15 May 2020

    Performance and security testing shifting left

  • 30 April 2020

    AR & ML Deployment in the Wild – A Story About Friendly Animals

  • 16 April 2020

    Cucumber: Automation Framework or Collaboration Tool?

  • 25 February 2020

    Challenges in creating relevant test data without using personally identifiable information

  • 04 February 2020

    Service Meshes – from Kubernetes service management to universal compute fabric

We are listening

How would you rate your experience with Endava so far?

We would appreciate talking to you about your feedback. Could you share with us your contact details?