Cross-posted at donald.merand.org.
According to Richard Feynmann, the true measure of understanding a concept is to be able to relate it to a toddler. This is what I love about the #explainlikeimfive channel here on Dev.to: explaining tech concepts in a couple of pithy paragraphs, without too much technical jargon, is a fun challenge to see if I myself truly understand the concept. I may have a problem with compulsively commenting on these discussions...
But there is one thing that bothers me: I'm not sure that the asker always wants an answer suitable for a five-year-old! Five-year-olds aren't typically concerned with specific terminology, but responses to #explainlikeimfive are often very jargon-heavy. The requester may have wanted that, but that's not an answer you'd want to give a 5-year-old! Not that it matters whether the requester truly wanted a 5-year-old response versus a 7-year-old response, or what-have-you. What truly matters is that when your response doesn't match the question, you run the risk of being ignored or misunderstood.
I think understanding these nuances is fun! I'm going to try explaining the same concept to a theoretical 5, 10, 15, and 20-year old. In doing this, I hope to learn something about my own process of teaching, and hopefully find some varying approaches that work well. I'll attempt to Explain Git + GitHub Like I'm Five (and Ten, and Fifteen, and Twenty).
One good way to #explainlikeimfive is to tell a short story which is an analogy. Five-year-olds aren't typically concerned with specific terminology, but they are very good at understanding metaphor. Your goal here would be to get them to understand how this idea solves a problem that's very similar to one that they may have had.
Say you are writing a short story and you want to do a really good job. You might write the story on one sheet of paper, and then get another sheet of paper and write another version, and then keep writing more versions on more sheets of paper. After a while, you'd end up with lots of sheets of paper that weren't the version you were currently writing. You might put those sheets in a folder so that you can go back and see old drafts of your story.
You give that folder to your mom to keep track of, because you know that you can always ask mom for one of the versions of your story if you need it. Plus, mom keeps photocopies so she can give versions of your story to your siblings. Mom also keeps similar folders for the stories that your siblings write.
Gitis the folder, and your pieces of paper are
code. Your mom is
Notice that in the story above, technical terms aren't integrated into the story, and the list of actual terms is drastically simplified (and could be omitted entirely without negatively impacting understanding).
Ten-year-olds are ready for terminology, but they can lose a thread if you digress too much or get too technical. You can still succesfully employ an analogy, but they also tend to enjoy more integrated references to technical terms. Thing Explainer by Randall Munroe is another approach that works - explain how a thing works using universal words and concepts, because at ten, people tend to understand all of the truly important concepts already.
Think of computer
appsas stories. Say you are writing a story and you want to do a really good job. You might write several revisions of your story. You don't want to lose your revisions though - what if you had a good idea earlier that you want to revisit later? So you decide to keep all of your revisions in a folder. You can think of
gitas the idea of folders that hold revisions, and your
repo) is the folder that holds this one story you're writing, and all of its revisions.
You might want to share the story that you're writing! Maybe you want to share the writing with friends, or maybe you just want a place for folks to go to read it.
GitHubis such a place - a web
appthat holds your
repos, and gives you a
web sitefor them to share. From
GitHub, anybody you allow can get their own photocopy of your story, and make changes to their copy. In
gitthat's called a
fork. If the person who
repowants to share their changes with you, so that you can have them in your
repo, they can give you a
GitHub- a bit like handing you a version of your story with changes in red, and asking you to use that as your story instead.
At fifteen, people are capable of truly excelling in areas that interest them. They can handle terminology and abstract concepts: metaphor, while helpful, isn't a tool you need to lean on quite so much. But you might still be dealing with a short attention span, so keep your descriptions on-topic and don't concern yourself too much with asides.
Say you are writing some code, but you worry that when you change your code you might want to
undoyour changes. So you need a
version controlsystem that you can tell "I've made some changes, please remember them".
Gitis an example of a version control system. Your
repois your code, which you
committo your version control system as you work. Later, you might create other
reposfor other code projects you're working on.
GitHubis an app that gives you a web site for your repo. Others can go to this web site, and download your repo to run the code, or make their own changes in their own copy (if they want to!). The idea of everybody getting their own copy of your
repoand being able to make their own changes to it is called
distributed version control.
GitHubgives you the ability to manage
Pull requestsare changes that other people have made to their copies of your
repo, that they'd like you to include in (or
mergeinto) your copy.
For a twenty-year-old, you can lay out all of your terms once, and then explain the concept using those fully-explained terms. A twenty-year-old can be expected to look up words in the dictionary, or check out concepts on Wikipedia, without needing prompting, so you don't need to belabor your explanations. Your job is to explain how those terms relate to each other. You can also diverge a bit into related topics without worrying that the person will lose track of the main thread.
version control system(
VCS), similar to
VCSis a system for
committingcode changes to a
repo) in an
append-onlyfashion such that at any given point you can see the history of all changes made to the code up to that point.
distributed version control system(
DVCS), meaning that if multiple people are working on the same code project, they each have an independent copy (a
fork) of the
repo, which can diverge from other copies. Changes from other copies (called
mergedinto a given
repothrough a text-based
algorithm. Changes in a given
repocan also be
merged later, to give the developer an opportunity to work on specific ideas without the pressure of
committingthem to the main
CVSrely on a central "master" code
server, which is typically referred to as a
GitHubis a web app that provides a social network around
GitHubwill give each repo a unique
URL, which can be used for
forkingor downloading a
pull requests, wherein a developer can
repo, create changes, and then request that those changes be
mergedinto another fork.
GitHubprovides other services such as
visualizationsof code history, and more. People often use services such as
Bitbucketbecause they don't want to have to manage their own git server, or because they want the extra features such as
Notice that this version is the first time that alternatives to Git, such as SVN or Mercurial, even get mentioned. I'm assuming that a twenty-year-old will want to do further research if they're interested, so providing bigger context such as naming alternative approaches can be very helpful toward that end.
Explaining things to people is fun! It is a good test of your personal knowledge on a topic, and it is also deeply rewarding to share knowledge with people who want to learn. Keeping your audience's abilities and desires in mind drastically increases the likelihood that what you say will be received and absorbed.
Do I think you should start using the hashtag #explainlikeimten or #explainlikeimtwenty just to be more precise? No, I do not! Please don't do that! I love that we have the one hashtag here which generally means "I'm new to this and would like some help." This was just a fun thought experiment meant to shed some light onto my own teaching process. I'm hoping that posting it here will be inspiring in some way!
Who have you found (here on Dev.to, or elsewhere) that's good at explaining? What is it that you like about their explanations?