Monthly Archives: March 2017

Montana Code School–Week One

Just as I was finishing my last post, I decided to turn in an application to the Montana Code School to see what happened. Once I submitted the short, online application (which was handled by Submittable – a Missoula tech company!), I went back and took another look around the Montana Code School website and realized that they had a part-time bootcamp scheduled to begin right away, as in the following week! Within a half-day of submitting the application I received a phone call from the school director wanting to set up an interview. So I went in for the interview on Friday and heard later that day that I’d been accepted to the part-time program.

While I’d been thinking of doing some kind of coding bootcamp, I wasn’t exactly prepared to act on the idea quite so quickly. I decided to jump on the opportunity for several reasons. For one, the price, while still significant, was much better than the online course I was considering. The timing also was good—I’d get to start on it right away and since it was part-time I could work on other projects at the same time. Possibly more importantly I’d be able to work with local classmates and get the support of the local tech sector through networking and other events. Since I’m only freelancing and doing odd jobs at the moment, I haven’t been as connected to the Missoula professional scene as I have wanted to be. I’m hoping that doing the code school will help in this regard.

Pre-work

At the same time the school sent the acceptance letter, they also sent a list of “pre-work” that they asked I complete. Probably about 40 hours of work altogether. Most students who had enrolled earlier than I had had already been working on it and were expected to have it finished by the first day of class. Since I wouldn’t get it all done before the first Tuesday, they said I’d be a bit behind for the first couple of weeks while I finished it but encouraged me to hang in there. The “pre-work” consisted primarily of a few online tutorials, mainly on the basics of Javascript, HTML and CSS, but mostly Javascript since it’s more complicated to understand than the other two. Javascript, as I learned, is a programming language used heavily in front-end (user-side) web development, though apparently it has some back-end uses too. Since it loads right into the user’s web browser, the user’s computer doesn’t have to continually call information from a remote server every time it wants to execute a Javascript function. This apparently cuts down on the wait time especially for certain complex web actions like animations.

image of compter and server interaction

How the HTML, CSS and Javascript code gets to your web browser.

Tuesday

The class meets regularly in a room at MonTEC (Montana Technology Enterprise Center), an office building which houses a number of local tech companies and startups. There are about 11 students in the class, many working full-time already and doing the boot-camp on the side. The first part of class was spent both on introductions and on going over some of the productivity methods that get used frequently in web development and that we’ll be using in the class, such as Kanban and Agile. We were then given a stack of sticky notes and asked to write down our “goals” “values” and “resources” as they related to the bootcamp. It was clear from some of the responses, especially for “values” and “resources,” that people were both excited and anxious about the learning ahead. A number of the “goals” that people stated were to be expected: earn more money, have a more meaningful work life, be creative. Others’ reasons were a bit more surprising initially, but made sense. One person mentioned the desire to combine tech with social justice. Amita, the school director, then mentioned that this was a reason more women are getting into tech. As an aside: I think this is actually key. If more people think first of what kinds of questions they can solve or explore through programming, they might be more interested in seeing coding not as an end in itself but as a means to other ends.

Our assignment for Thursday was to start creating a website with the HTML and CSS we had learned so far.

Thursday

Austin, our instructor, introduced GitHub, the command line and then had us continue work on our basic websites. I’ve known about the command line (Terminal on macs) for a while, but it’s always been super intimidating and I’ve been convinced I’m going to break something or lose something if I use it. Apparently there are a lot of advantages to getting used to the command line though, such as saving time when navigating through your folders and files. It’s also how Austin wants us to “push” our work to GitHub. I’m still scared of the command line, but now that I know a few commands it’s a bit more accessible. One thing you probably don’t want to do from a command line is to remove something. Unlike dragging it to the trash on your desktop, removing a file in the terminal will probably delete it permanently—as in forever. Scary.

I’d played around with GitHub for a short time before the class started, but found the workflow hard to grasp. Basically, GitHub is an online repository for coding projects. That is, it’s a kind of cloud storage for your project files, but also serves as a version control platform. Every time you make changes to your files on your home computer and then “commit” and “push” those changes to the repository in GitHub, it stores a version of those changes that you (or others) can later access. It’s useful if you make a change that results in your code “breaking” (a.k.a “not working”). You can go back to an earlier version to help identify which changes were responsible for the code breaking. It’s going to take me some time to get used to GitHub, but I can see where it can be super useful, especially for collaboration.

Career Change + Coding

When I started this blog I said I would share my experiences and learning about instructional design as a career field.   I also promised to tell about my own career transition with the hope that something in my experience might be helpful to others. In the end, it may be this latter goal that becomes the more significant one. In the two months or so that I’ve been looking into the instructional design field my thinking has already shifted, both in terms of my understanding of the field as a whole and of how I want to position myself within it. Since the ending to this career transition story isn’t written yet, it’s entirely possible that instructional design is not the area I want to move into. Only time and more experience and research will tell. Consequently, I think it will be instructive, both for me and for my readers, to explicitly reflect on my learning process from time to time. And so with this in mind, let me tell you about my current adventure! This will be a story without an ending (at least not yet) as it is still unfolding. But before I begin recounting my current saga, I have to take us back in time a little bit.

Exploring Web Development

I first thought about moving into the instructional design field back when I was still employed at the University of Arizona. I had been using the Desire2Learn learning management system (LMS) heavily for my courses, was experimenting with “clickers” (Classroom Response Systems) and was getting some exposure to the technologies in use in higher ed. Mostly, though, I was not a techie. I’d never coded, never played or been interested in gaming, and didn’t really know the first thing about digital technologies. Outside of what I was doing for my classes, the closest I’d come to working in the digital space was creating a couple of WordPress travel blogs (you can see them here and here) and playing with my iPhone. When it became clear I wouldn’t be staying in my faculty position (a blog post for another day), I started reflecting on my options. I figured it couldn’t hurt to have some technical knowledge regardless of my ultimate path, so I looked online for some free resources to help me learn more about HTML (Hypertext Markup Language) and CSS (Cascading Style Sheets). I found Codecademy and started working through its HTML tutorial. I didn’t get very far into it when I got offered and then accepted a job teaching high school in China. With an overseas move on the horizon, I put off learning more about web development.

Flash forward to this past summer. My high school teaching contract was up and I decided to come back to live stateside. For personal reasons I’ve ended up in Missoula, Montana and have decided to make a go of it here one way or another.   After another side excursion into educational consulting (another blog post for another day), I have come back to the idea of teaching and learning, and especially instructional design and educational technology. Given my self-imposed geographical restrictions, I thought working in edtech would both allow me to remain connected to education and be something I could work on remotely if needed. I’ve also always loved planning and design work. Developing courses, planning and writing curricula and creating learning activities have been the aspects of teaching I’ve always had a passion for, so I thought some kind of edtech development work might be a good fit for me.

To learn more about instructional design and digital learning I set up a couple of informational interviews, both with professionals involved in online learning in higher ed. From them, and then subsequently from reading websites like O*Net Online, it’s become clear that I’m not going to get very far without some background in multimedia production and/or web design. And so I’ve been investigating several different learning options to see which might work best for me in my current situation. So far I’ve narrowed it down to three different paths: studying on my own with books and websites, taking a class or two in Media Arts at the University of Montana, enrolling in an online coding bootcamp like Bloc, or attending a residential coding bootcamp like Montana Code School. I still haven’t made a decision about which of these to choose, though at the moment I’m leaning toward just self-study with some media arts classes or an online coding camp. While a residential camp isn’t off the table, it would have to be Montana Code School since I’m not willing to move for it. The costs associated with relocation added to the cost of a coding bootcamp make the whole thing prohibitive, at least for me. Independent study, while certainly the least expensive option in the short-term, has its drawbacks. Not yet having a technical background or many contacts in the tech industry, I do worry about getting the kind of mentorship that I need. Finding good mentors was always a challenging proposition, yet I’ve learned the hard way that mentoring is crucial to getting you where you want to go. It also ties in with what I’ve learned about collaborative learning and communities of practice in the Coursera eLearning Ecologies class I’ve been taking. While I’m sure I could learn quite a bit just by reading on my own and building my own projects, I think I will need someone I can ask questions of, who can critique my work and who can give me an insider’s perspective on the web development industry. Mainly for this reason I’m thinking hard about online coding bootcamps. I’m especially interested in Bloc because it offers a special designer track where I could get training in both user experience (UX/UI) design processes and applications and some front-end development (the user side of the web). But I’m also trying to talk to a few people I know in the tech world to see whether they think it is worth the money since, like other bootcamps, “they ain’t cheap.” In the meantime I’m starting my own self-study program with books and websites. Even if I decide to do a camp, I’ll still do my own reading and investigation. So you can look forward to future blog posts from me that provide more detail on my web design learning! If anybody has any experience with coding bootcamps, especially the online ones, please leave a comment and tell me about your experience.

 

 

Book Review: Design for How People Learn

Julie Dirksen’s book, Design for How People Learn (San Francisco: New Riders/Pearson, 2016), came recommended by Connie Malamed on her list 12 Instructional Design Books You Should Know About. Since Ms. Malamed has also written a review of the book, I won’t go into details about the content. You can read Ms. Malamed’s review here.

Modeling Good Instruction

In many ways, the strengths of Ms. Dirksen’s book lie in how she models the very design strategies she recommends. Her presentation style is conversational and engaging and easily serves as a Dirksen_book_imagemodel for how to communicate information well. The relaxed tone, combined with sometimes irreverent humor, lighten and enliven the theoretical points she has to make. Likewise, her frequent use of scenarios helps illustrate the more abstract design concepts. She is adept at combining text, graphics and a range of explanatory techniques to present complex information. For example, to give the reader a clearer picture of cognitive functioning she builds on a curious, but effective analogy. First proposed by Jonathan Haidt in The Happiness Hypothesis (2006), this analogy suggests that an elephant rider can stand in for the conscious, verbal thinking part of the brain and the elephant itself acts like the emotional, visceral brain.
Through a serious of humorous photos, image captions and explanations, Ms. Dirksen both discusses the analogy in more detail and considers the implications this understanding of the brain has for learning [124-27].

Ms. Dirksen regularly integrates graphics of various kinds (e.g. photos, line drawings) into the text. They are often deployed in ways that reinforce the contrasts or progressions she is describing. Additionally, she uses headings and subheadings liberally. These, combined with the graphics, help chunk the content so that the reader isn’t overwhelmed with large amounts of text. A book intent on introducing brain science and instructional design methods could easily get caught up in abstraction and technical descriptions of research. A strong point of the book is that Ms. Dirksen avoids the technical jargon while still firmly basing her points on the relevant psychological and brain science research. I also appreciated the amount of time Ms. Dirksen spent discussing design techniques for enhancing motivation and emotional engagement. As a new teacher, I remember being primarily focused on the ability of my students to acquire knowledge and build skills. I soon learned, however, that very few students were going to acquire any knowledge I had if they weren’t first motivated to learn it. By devoting several chapters to these learning challenges and the design solutions for them, Ms. Dirksen clearly demonstrates her understanding of key conditions for learning.

Limitations

The title, Design for How People Learn, suggests that the book could potentially address learning in a very broad sense. Indeed, the focus in a couple of the early chapters on memory and brain functioning could be useful for anyone with a beginning interest in cognition and memory. Nevertheless, it becomes clear that Ms. Dirksen is addressing a particular audience and has developed her book with new trainers and instructional designers in mind. Given Ms. Dirksen’s own experience with corporate training environments, it’s not surprising that she frequently includes stock photos featuring office work and creates scenarios that involve trainers and sales staff. Her choice to appeal to this audience and to focus primarily on the corporate context, however, leads her to make several key assumptions about the goals of learning that are problematic. Consequently, her design solutions don’t really speak to the true range of adult learning situations.

One working assumption in the book is that learning is primarily individual and cognitive. That is to say, learning is about a person getting knowledge into long-term memory. As has become clear to me through my own humanities research and through engagement in the Coursera eLearning Ecologies class, memory and learning are highly social and environmental. I’m reminded, for an immediate example, of the studies that show how a person’s ideas of acceptable body type (and ability to gain or lose weight) can depend on whom they socialize with. While it is certainly important for workers to commit information to memory so that it can be immediately accessible, most work (and living) is not done in isolation. The collective wisdom of teams is often of greater accuracy than individual memory anyway, so it makes sense to leverage it in learning too. For example, one would expect an EMT to be able to recall certain information from his long-term memory. In a life-threatening situation it doesn’t make sense for an emergency worker to be looking to a job aid or reference card. But really, how often do EMTs work alone? In most cases, I would imagine, emergency workers have to work with a partner or as part of a team. In training EMTs, then, wouldn’t it make more sense to focus on ensuring that the EMT can work with his partner so that their collective knowledge can be used most effectively? To concentrate primarily on developing individual cognition is to ignore the real contexts in which people work and live and remember.

The belief that learning is about individual memory, however, rests on another set of assumptions: that improved workplace performance is the goal of learning and that tracking individual performance is the best way to understand if it is happening. Assessing employees’ performance depends on having an accurate understanding of how learning interventions have worked. Companies usually rely on measuring of one kind or another, since social science and business researchers typically use quantitative methods in their analysis. If we accept that a person is a definable base “unit,” individuals become easy to track. One could measure the performance of larger groups (and I’m sure companies do), but the makeup of teams and groups can change and the quality and quantity of individual contributions to group work may be very diverse. This makes evaluating workplace performance difficult, particularly if the goal is to identify talent for promotion or to pinpoint areas of individual weaknesses. Unfortunately, this approach operates on an unsophisticated understanding of the nature of individuals. Biologically it may be fairly easy to identify an individual. But, as much humanistic, sociological and brain science research has shown, people are tied up with other people and the environment in ways that make it very difficult to see the lines of division between them. Developing learning interventions that are measurable may still be a worthy goal and yield important information about the quality and extent of learning. It is important to understand, however, that there are many other possible goals of learning beyond improved workplace performance and that there is likely quality learning happening that will never be revealed through quantitative measuring.

Consequently, the design solutions provided in the Design for How People Learn work best for shorter-term training programs whose effectiveness needs to be evaluated for external reasons. They do not really address the development arc of fundamental skills, such as critical thinking or the so-called “soft skills,” that require more instructional engagement over a longer span of time. To her credit, Ms. Dirksen recognizes that the atomized interventions she mainly describes are not intended for this kind of learning [73-74]. While she also does pay attention to social and informal learning and to designing learning for the environment, she views them primarily as supports to other kinds of formal instruction rather than being primary methods of learning. Given the corporate concern with team work and a growing breakdown of traditional reporting structures in modern business environments, however, it would seem that helping workers learn through collaboration would be part of a trainer’s basic job description.

In any case, Design for How People Learn is a worthwhile read. Many of the design suggestions are easily transferable to a range of instructional contexts. I would go so far as to recommend this book to anyone interested in communications and marketing as I think her recommendations for increasing motivation and supporting habit formation could be used to increase audience engagement generally. Nevertheless, it’s important to keep in mind that a different world of learning exists outside the corporate environment, that learning isn’t always easily evaluated, and that learning has value regardless of its ability to contribute to an organization’s profitability. If a reader looking for an introduction to instructional design can keep these caveats in mind, she will find much of use in this book.