Do instructional designers (IDs) need to know how to code?

While researching this question, I found this gem on Cristy Tucker’s blog. She did a wonderful job looking into skills listed in job descriptions for instructional designers. Based on Cristy’s findings, here are the top five programs or skills you need proficiency in to succeed as an ID:

1. MS Office

2. Adobe Flash

3. Adobe Captivate

4. multimedia

5. Adobe Dreamweaver.

Runner ups were Photoshop, web conferencing, and HTML.

Well, of course, the year was 2007. Historically, we had IDs doing the analysis and design part of the job, then handing over the storyboard to the developers. Developers were the cool people, making magic happen in Flash. Developers would often require “approved” content before they would start coding in Flash’s ActionScript.

An ATD survey from 2015 shows that IDs still consider soft skills their priority (as opposed to coding or programming). Yet, one of the top challenges IDs reportedly face is the insufficient time to develop content; 37 percent of them report that IDs are often the last ones to know of changes in the organization that affect their work. The last ones to know! This made me wonder how our self-reported priorities are aligned with the general business needs.

In my book, Engage the WORL&D!, we explore six traits (critical thinking, CREAM, adaptive resilience, human-centered design, social impact, and myth debunking) that may help instructional designers move from content wrangling to problem solving by expanding the boundaries of what instructional design is.

The boundaries between instructional designers and developers are more fluid today. Some IDs develop materials using rapid authoring tools, or even code in straight HTML5. Others are still focusing on the analysis and design realm (maybe evaluation) only. Connie Malamed collected some current ID capabilities, building on her previous blog on the topic.

In today’s world, while it’s not necessary to know how to code, it does give you an advantage in the field to stand out. Forbes magazine lists eight jobs that are easier to land if you can code. I’ll leave you with guessing the other seven, but one of them is instructional designer.

Thinking Like a Programmer

Having learned several programming languages (BASIC, C++, PHP, Java, and JavaScript), I must agree, the ability to code opens more doors and widens the horizon of solutions you can create. Yet, my advice is not to learn how to code unless you’re into that thing. You will be frustrated if you’re not a coder-type.

However, I like to think that there’s a difference between programming and coding. And that’s the message I’m hoping you take away from this blog post: While you act like a designer, you think like a programmer.

The words programming and coding are mostly used interchangeably. Coding is picking a language, and expressing those ideas that existed in the mind previously, now in lines of code. Programming, on the other hand, is the process of defining those ideas in the first place.

While coding is literally about writing lines of code, programming has a broader meaning. You can program an application, a washing machine, or a game engine without writing a single line of code. With artificial intelligence–powered applications and intelligent robots, programming might be a basic literacy skill in the future. For me, programming is about the logic. It is the mindset, the way you approach problems, the design pattern you’re applying. Thinking like a programmer is a good way to move from content wrangling to problem solving.

Practical Takeaways From Programming

Let’s look at six aspects of thinking like a programmer, and how they could help you design better learning experiences:

There are no “next slides” and “next buttons” in programming.

Programming is both holistic and task-level thinking: You treat every project as a system. Systems thinking requires you to both analyze and synthetize. For example, for system applications, you must be able to break down complex processes into discrete tasks. At the same time, every programming decision you make on the discrete task level must support the overall user experience and user stories. Programmers don’t think in content slides.

Variables allow flexibility and adaptive learning.

A variable has a name (so you can call it whenever you need), a type (to let the system know if it’s a number, text, or so on), and a value. The value can be changed any time. That’s why it’s called a variable. Variables can keep things in memory. They’re not saved (normally) anywhere, so if you close the application, they’re reset. Of course, you can also save them in a database or learning management system if you wanted to preserve them. Variables provide flexibility to adapt to each user’s needs.

Conditions allow interactivity, making choices, and personalized feedback.

Conditions are if-then situations. If something is true, an action is triggered. This is the base for branching. Branching breaks linear thinking, and allow users to learn through their own decisions, feedback, and consequences. Simulations, for example, need a lot of conditions. Conditions also force you to think in digital states: Let’s say you want to add a toggle button for music, on and off. When you think like a programmer, you picture a variable storing the value, as well as the user interface representation on the screen. They are not the same! The variable is invisible for the user; it only exists in the code. The button is an interface element for the user to interact with the variable. When you think like a programmer, your mind explores the states the button may have (on and off, maybe disabled?), and the value of the variable (true or false). Variables should have an initial value. That’s the value before any system or user interaction would change it. So, you need to decide if the button is on or off, and set the variable and make sure it matches the button’s state on the screen. Clicking on the button (if enabled), should toggle the value; therefore, you need to build a logic to flip the variable, and change the state of the button when the user clicks. See how a simple little thing causes so much thinking if you’re a programmer?

Troubleshooting is a lifesaving skill.

Troubleshooting (or debugging) is the process of closing the gap between what you actually coded and what you meant to. Troubleshooting is the most essential skill you can learn! It is one of the most sought-after capabilities in the workplace. It takes both knowledge and skill (and sometimes a lot of luck) to be good at troubleshooting. You need to have an idea of what can go wrong to formulate a hypothesis. Following the hypothesis, you need the skills to isolate the problem, assess dependent and independent variables, and test over and over. This is an iterative process. If you change the system too much, you may introduce more instability. If you don’t have a solid hypothesis, you may troubleshoot forever. The more troubleshooting you do, the faster and more efficient you become at it.

Commenting is essential for sharing.

There’s nothing more foreign that looking at your own code months after the release. Commenting is painful. It slows you down in the heat of the moment, but it is a lifesaver afterward. Commenting is documenting your thought process. Sharing your comments can help others learn, not only the what and how, but the why!

Functions are like heated seats in your car in the middle of winter.

Finally, a little more advanced feature: functions. Functions are something like heated seats in your car. You can live without them, but once you experience them, you can’t believe how you survived before. In its simplest form, a function is a task you need to repeat multiple times, so instead of writing the same 50 lines in your program over and over, you do it once in a function, and you give a descriptive name to it. Then, you just call the name of the function from anywhere to do whatever it has to. You save tons of copy-pasted lines, which makes your code more efficient in the first place.

As an example, in an e-learning course, we separated the data and the course logic itself. The data was coming from an external file (XML). A function read the file content when the course was launched, and populated the content. This allowed us to have the exact same course in different languages without republishing the course itself. In this case, the function’s job was to read the data from an external file, and then return it as usable content for the course. Any light maintenance on content could be done by just editing a text file, without touching the course itself.

Want to Think Like a Programmer and Act Like a Designer?

If you’re interested in the advantages of thinking like a programmer and acting like a designer when using the Articulate Storyline authoring tool, come to the ATD TechKnowledge 2018 workshop, Tears of Laughter Method: Advanced Articulate Storyline (Variables, Triggers, and Conditions).