Top
1.800.628.2783
1.800.628.2783
Advertisement
Programming code abstract technology background of software development-23924
Insights

Think Like a Programmer, Act Like a Designer!

Wednesday, January 17, 2018
Advertisement

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.

Advertisement

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 ).

About the Author

Zsolt Olah is a senior program manager at Comcast University’s product knowledge team. He oversees the product knowledge training curriculum, specifically for the X1 Entertainment Operating System, and provides cross-functional leadership for innovative learning solutions, including game-based learning, gamification and game thinking within L&D. Zsolt has extensive project and program management background, as well as more than a decade of learning and development experience, focusing on the synergy of creative learning solutions and technology. 

 

Zsolt’s passion to combine creativity and technology goes back to his thesis, which was to build an artificial neural-network in C++ capable of learning how to add two numbers together. Since then, Zsolt has worked in the instructional design and e-learning field with companies such as Pepsi, Nokia, Siemens, IBM, Oracle, and for the last seven years, Comcast.

 

Zsolt is well-versed in most of the top e-learning applications and game engines, and has working knowledge of several programming languages. Zsolt has also designed and taught an information design and delivery university curriculum for the University of Debrecen, in his native country of Hungary.

4 Comments
Sign In to Post a Comment
Hah! Nice to see that old blog post referenced here. I wonder what I'd find if I looked at job postings now and how much it has changed in the last 11 years. Do you think employers understand the value of the soft skills and the mindset you discuss here to look for it in candidates, or even to list it in job descriptions?
Sorry! Something went wrong on our end. Please try again later.
Interesting article. Prior to becoming an Instructional Designer, I was a Project Manager and a Programmer. I always found that systems theory helped me with Instructional Design and that my main task was learning human pedagogy. I like your thoughts and wish more of our fellow professionals would think this way and relate some of thoughts to SMEs.
The logic (Spockness for you Trekies) is very important and has much to do with a clear flow and successful design.
Sorry! Something went wrong on our end. Please try again later.
Hello Zsolt, Very good read. I completely agree. It is important for the designer to become the developer in my opinion.
Thanks Blanka! While becoming a developer may not be for everyone, and that's perfectly okay, we can still steal and repurpose some of the problem solving aspects of a programmer's mind to think beyond content.
Sorry! Something went wrong on our end. Please try again later.
Sorry! Something went wrong on our end. Please try again later.
Sorry! Something went wrong on our end. Please try again later.