I taught a lot of Dynamo workshops when I was the “technical evangelist” for the Dynamo team. I’ve learned a lot about how to teach over the years by making mistakes, getting it right sometimes, and picking up ideas from other teachers more gifted or experienced than I am. If I ever had the opportunity to share Dynamo knowledge with you, Dear Reader, I’ve learned from you too, so thank you. If you’re reading this, you’re likely a current or future teacher-of-Dynamo yourself, and hopefully my experiences can help make yours better. This post is a set of lessons-learned, packaged into a set of ten, that may help you teach Dynamo. Some of this is general advice about teaching, some is more specific to teaching software, and some is specific to Dynamo itself.
My general philosophy is that the goal of teaching is that learners learn, not that the instructor look good, or that the software appear flawless. If nothing else, a good teacher will channel their own former-self by remembering and reacting to all the frustrations they had when they were sitting in the student’s chair.
[0] Take your time on the basics.
- Be overly generous with time spent setting up a structured mental model of what’s going on. Whether students will admit it or not, almost every class represents a diversity of backgrounds and skills. If you’re worried that some people will be bored, remember that even people who are experienced may never have heard a structured explanation, or they may benefit from hearing yours. Too basic is probably not too basic at the very beginning; don’t leave anyone at the starting gate.
- Give two-to-three different explanations for each of the tricky basic concepts: series creation, list lacing, List@Level, List mapping, replication, and data types and structures.
- Diagrams are everything; take every opportunity to make connections between abstract list structures with geometry (like with Show Labels).
Ex: Use Show Labels to demonstrate that the order of items in a list applies to the corresponding geometry too.
Ex: When showing the properties of 2-D data, use points organized in columns versus rows, and make sure that number of points in each direction is obviously different to avoid the appearance of relationships that don’t exist. Using small numbers like 3 rows and 5 columns is visually distinctive, and it’s obviously a different data structure when transposed.
- Teach through repetition. Even after covering the basics formally, revisit core concepts every chance you get, even to the point of making a joke about it if the mood of the room calls for it.
Ex: “See that classic diagonal line of points showing up? It’s a lacing issue, because each item was matched only to the corresponding item in the other list. We want every item in the first list matched to every other item in the second list, so think: “Cross Product!”
[1] Set clear goals with human language before you script.
- Motivate each of the technical lessons. You’re not telling people something for the sake of talking; there’s a use case.
Ex: “See how when we connected each of the sets of points to make lines and it just worked? You have other options there too that can be useful if you want something else to happen.”
- No surprises. Tell people where you’re ultimately going and why. A measure of your teaching efficacy is how well students can anticipate the next steps. Help them by being clear about where you’re going.
Ex: “We are going to build a single truss form with lines that we will then apply to more complex situations. The inputs will be a base curve and the number of divisions. This will be a way for us to run into issues involving series and basic list management.”
- Support advanced users by encouraging them to experiment and work ahead. Suggest challenges for the most eager users beyond what you’re covering with the full group.
Ex: “If you want to try it, see if you can place more than one type of adaptive component.”
[2] Acknowledge and encourage solution diversity.
- Defeat the idea that there is only one way to do something. Just like in high school math class, some people fear most that they don’t know “the right way” to do something, which can be paralyzing. Help them understand that there are many alternatives, and they don’t have to be fancy.
Ex: “We could take the first item of each list by using List.FirstItem @L2 or if you didn’t think of that, remember that you could also use List.Transpose then List.FirstItem.” [Demonstrate this while describing it.]
- If someone ever challenges you with a question like: “Couldn’t you also use that other node? Wouldn’t that be faster?,” embrace it! It’s a great opportunity to explain why you chose a particular path relative to what they suggested, or if it didn’t occur to you, say so—your students will only relate to you better when you’re honest. If it’s as good or better than your idea and you’re up for a side trip, try their solution to compare. Otherwise, encourage them to try it themselves while you move on.
[3] Empathize with the student’s perspective.
- Move the graph only rarely and only with good reason. Students should be able to glance at your screen and be oriented quickly.
Ex: Newly placed nodes are easier to find on your screen if they are next to existing nodes that haven’t moved, so make some space for new nodes well in advance of when you place them.
- Zoom in far more than you think you need to. This large-scale allows people to glance at your screen and understand it quickly without having to strain.
Ex: Zoom in to fit just 3-4 nodes on your screen most of the time. The set of nodes should make a single thought like the set: {File Path, File.FromPath, Excel.ReadFromFile}.
- Make your policy very clear that you will zoom out or pan back to the left any time anyone needs to see more. But err on the side of too zoomed-in.
- If you need to pan your script a large amount, zoom all the way out first to help people become oriented with where you are headed before you zoom in again.
- Maximize the Dynamo window whenever possible and hide the library on the left to increase your screen “real estate.” (And as always, say what you did to hide the library since your screen would look different from theirs.)
[4] Guide with words as if no one can see your screen.
- Never, ever say “there” or “here” when pointing something out. Always use words to describe what you are referencing so that people who are not looking up at your screen at that exact moment can still follow.
Ex: Say “Connect the wire to the second port where it says Keys.” Never say: “Connect the wire over here.”
- Avoid making all unnecessary little tweaks to your graph or to your screen. Help a student to follow you, knowing their attention must be divided between their screen and yours.
Ex: Don’t pan a centimeter to the left just to make it look better. It may make it look better, but it is harder to follow when the visuals are constantly changing.
Ex: Never undo something or “fix” your own mistake without explaining what you did and why.
- If you must type something, read it out loud as you type.
- If you must go “back in time” to fetch an output from a node far off screen, always say why you need that node’s output and why you can find it where it is. Describe the node itself, not its position because students’ screens will look different than yours.
Ex: “We need to operate on the Revit elements themselves, not their geometry. The last time we had a list of the elements was in the All Elements of Category node near the beginning.”
- Describe all funny, non-obvious behaviors at least twice.
Ex: “To turn off the preview for multiple nodes, select them all and right-click off to the side to find the option in the context menu.” […Pause…] “If you right-click on just one node, you’ll only see options for that node alone, so you have to click off to the side to see options for the collection of nodes.”
[5] Teach by example.
- Keep strong graph organization: all inputs on the left, build your script from left to right, and add annotations and groups as appropriate. You are helping people establish their own good habits.
- Chose meaningful names and descriptions so that students learn good habits.
Ex: Write “windowArea + wallArea” instead of “x + y”.
- If you reorganize nodes, say why.
Ex: “I’m moving these nodes up and out of the way to make some space.” Or: “Let’s stack these nodes together because they do similar things.”
- Treat the Dynamo graph as a diagram itself.
Ex: If a node finds points for the top of something, put it physically above a node that finds points for the bottom.
[6] Keep the class flowing.
- Maintain a slow-to-medium, predictable pace. Slower learners will understand that they have to move a bit faster, while faster learners will know how much time they have to experiment with other things. Just be consistent so people can plan.
- Pay attention to your slowest students to make sure they’re not left behind, but jump them forward by giving them the current state of your correct file if necessary.
- Watch for people who look confused to help you know if you are moving too fast.
- At critical steps, walk around the room to verify that everyone is on the same page. Often people who are very behind won’t feel comfortable admitting it publicly, so this is your chance to find them and help them.
- Take breaks about every 90 minutes for relief and to address falling energy levels.
- If you decide to demonstrate something with Dynamo, perhaps to answer a question, be clear to students when they don’t have to follow you and when they should resume following you.
Ex: “To answer that question, I am going to make a small demo off to the side. You do not have to follow along for this part, just watch.”
- Pause frequently to let people catch up and digest what you’re saying. Don’t be afraid of silence!
[7] Encourage open participation and questions.
- Start the day off with introductions. Introduce yourself and ask students to introduce themselves, their background with scripting or Revit, and what they hope to get out of the class. Besides helping you decide what to emphasize later on, this exercise breaks the ice and allows people to feel more comfortable talking later.
- For a group of 20 or fewer, clearly state a policy that questions may be asked out loud at any time and that interruptions are encouraged. Larger groups may require a policy of raising hands or the class may require the help of a teaching assistant to manage questions. Either way you chose, be clear about your operating procedure.
- Ask the group questions periodically that have the purpose of helping people think critically. Questions should be non-trivial.
Ex: Ask something like: “Before you plug the wire in this new node, what should we expect it to do to the list structure?” Avoid trivial questions like: “And we find the sum of two numbers with which node?!…”
[8] Show the dirt. Don’t hide odd features.
- The fundamental goal of teaching is that students learn, not that the software look good, so if they have to know to watch out for some strange behavior, let them know.
- Users will run into bugs, un-obvious logic, and possibly un-intuitive behavior all on their own, either during the session or soon after. Help them understand that it’s not always their fault; the worst thing that can happen is that they feel intimidated or frustrated.
Ex: “To pin open a node’s preview bubble, hover over the central gray part of the node, then move your mouse slowly down over the preview bubble, wait for the “pin” button to show up, move your mouse over to that without leaving the preview bubble itself, and click the button. It may not be easy the first time, but don’t worry, it’ll be second-nature soon enough.”
- With at least a few examples during the day, try to intentionally work toward creating a problem or error, then explain it and solve it.
Ex: “The StructuralFraming.BeamByCurve node turned yellow and some of the output values are null. If you look, you’ll see that the null items happened for each of the PolyCurve inputs we fed it. This is because Revit doesn’t have a concept of a PolyCurve so the operation didn’t work. We’ll have to extract the individual curves from each of the PolyCurves first before this will work correctly.”
[9] Fix code together. Learning to debug = learning to script.
- Show students what error messages say and do your best to interpret them. If possible, after explaining the meaning of the warning, let them connect the last step of logic on their own. Otherwise give them the full answer and describe why you know it.
Ex: “The error message says that the index is out of bounds. That means that the structures of the two lists you supplied don’t quite match. See how this one is a flat list and the other one is a list of lists?” […Pause…] “The items in each of these lists are supposed to match one-by-one, so we could flatten the complex list so that they both have parallel structures.”
- When someone runs into an issue by accident earlier than you planned, describe to the whole class what happened and why. These are all teachable moments and a major value-add to in-person learning over video tutorials.
Ex: “On this machine, we have the problem that the computer can’t connect to the internet to search the package manager to find the Ampersand package. In case you need to know, there is also a manual way to install packages. I’ll show you with my computer, but if it worked for you to download Ampersand from the package manager the easy way, you don’t have to follow me, just watch.”
- Acknowledge and point out your own mistakes if you make them. It’s encouraging to students because they will make plenty of mistakes too, and it also builds trust.
Ex: “Oh, with the last node, I get a null value. The error message says that the node could not find a version with that input. That means I accidentally plugged in the list of geometry instead of the list of Revit elements I had intended. If you did this too, fix it by connecting the wire from the Select Model Elements node.”
Have I missed anything? I’m sure the community can benefit from your input to. Leave a comment and let’s continue the discussion. I wish you much success teaching Dynamo yourselves!