Novice struggles and expert blindness: How my discomfort with PHP will make me a better instructor

It was my third blank screen. I switched back over to my text editor and tried again. I looked at the format of my PHP, looked at my functions. I looked up the PHP documentation, deleted elements that did not seem right, and saved again. Back in my browser, the screen was still blank. Last week, my computer at least gave me an error warning to let me know I had incorrect code. Today, there was nothing—even the static html components failed to appear. At this point, I had no idea what to do. I had exhausted my knowledge of PHP, exhausted my understanding of what to look for or how to fix it. After two straight hours, I was frustrated, overwhelmed, and tired, yet had nothing to show for the time and effort I put into it. It is the first time I remember feeling like I would and could never build the competency I needed to complete our remodel of Ivanhoe. I felt inadequate. I felt stupid. I made excuses that maybe I just was not ‘meant’ to work with computers.

Last week, Steven Lewis blogged about his own difficulties with our PHP homework.  For him, the challenge is not that the PHP is completely unfamiliar, but rather than it incorporates elements of English that are familiar, though not used in a familiar or intuitive way. This is a key observation, for it shows how we try to make sense of the PHP based on our own experiences and cognitive framework. We see symbols that look familiar and try to use them and read them in a way that already makes sense to us. I have used this type of association in the past when learning new languages; in order to make sense of an unfamiliar language, I look for cognates or contexts and grammatical elements that look familiar based on my experiences with English. Of course, this process works better for some languages than others (for examples, there are less similarities between English and highly inflected languages or languages that use different scripts), but it nevertheless reveals how we learn by association and then application based on our established knowledge set.

So on one hand, I understand how this comparison of code to language can make PHP look deceptively intuitive, especially when symbols work in a way that is unfamiliar to our native language. For me, however, the challenge is less the code form as it is the logic behind it. The logic of PHP is more mathematical than grammatical, more literal and precise than our everyday language. This difference has been my biggest obstacle, for while I can memorize and regurgitate the system of code, I still struggle to grasp how all of the pieces intersect and how to solve problems when they arise.  I still cannot apply my knowledge to new contexts, cannot see how one set of tasks are similar to another, cannot anticipate how literally the computer will process my command. Even the resources available to consult are new and unfamiliar; traditional experts and peer reviewed publications are replaced by flexible online forums with an overwhelming number comments suggesting alternative approaches and opposing advice. Last week was a low point. I was frustrated and depressed; I did not know how to start or even which questions to ask when given the chance. It felt hopeless and I had the strongest urge to give up.

I am familiar with the concept of “expert blindness,” but had always associated it with content, assumed that an expert knew so much information that they were unable to unpack it and introduce it in an order that made sense to someone new to the field. My PHP-exhaustion last week, however, expanded my understanding of expert blindness to incorporate not just information, but also skills. It has been years since I have been truly stumped, completely unsure how to even proceed, let alone succeed. Over the past 10 years as an undergraduate and graduate student, I have not only expanded my knowledge of my field, but also developed proficiency in the tools and skills necessary to analyze and present that knowledge. If I run into an issue with my research, I know who to consult, which publications to scan, how to read the plans and diagrams, what professional expectations to meet, and how to integrate that information with the vast compilation of knowledge I already have. In other words, I can apply my knowledge to new contexts and problem solve so efficiently that I cannot remember a time when I could not. My own expert blindness crept up on me, affecting not only how I learn, but also how I expect others to learn.

As an instructor, I have always tried to established clear learning goals and to execute them in a way that engages the students actively. I have constructed assignments to help them learn new vocabulary, develop their writing, and analyze the formal qualities of an unknown artifact. Looking back, however, I recognize moments when I took students’ knowledge and skills for granted because they are things I do without thinking. Most recently, I remember asking my students to analyze a building plan in order to identify different housing forms and, therefore, different eras of construction. While I lectured on these structure forms in class, the students’ papers revealed that some did not understand how to read the plans I introduced. When a plan shows building walls with varying thicknesses of lines, it is not at all obvious that other line variations showing stages of construction do not in fact display real striations or stipulations in the landscape. While I was able to revisit the topic in class after recognizing my lapse of instruction, it made me realize how much we gloss over–especially in lecture courses–and how easy it is for students to repeat that information correctly on an exam even if they do not fully grasp it. I wonder if my students ever felt as I did during my PHP exercises—confronted with a task or certain methods that frustrated them, throwing everything they had at it with no particular order or insight. I wonder if I then interpreted their regurgitation of my own words as deep and meaningful learning. How many students drop classes or majors because they were frustrated and felt they could never understand? Is there a better way to present course content, not to get all of the content in, but rather to ensure that the students come away enlightened and enriched by what they confronted, confident that they can continue to develop those skills not only as students, but also as life-long learners? How do we encourage them to ask questions, even if they seem too broad or simple? While I came to the Praxis Program hoping to gain concrete digital skills, I will come away with a renewed affinity with my students as learners confronted with something so new that it challenges them. As academics, it is often very easy to stay within the established bounds of our disciplines, very difficult to get out of our comfort zones in order to learn something (anything) that requires completely different skill sets than our own. I wonder if we should perhaps make this discomfort a bigger priority within the graduate curriculum in order to broaden our thinking as researchers and think critically about our methods as instructors.

My frustration with PHP is not gone, but my realization that this frustration is a natural part of the learning process–something I expect my own students to experience–helps me push through it. We are now working directly with the Ivanhoe code and the practical application of more abstract concepts allows me to see concrete results. By creating my own localized git branch, I have been able to play with the code on my own terms, to change something and see how it affects the site in a low stakes setting. But I never would have made it this far without the support and encouragement of the dedicated Scholars’ Lab staff. They have a willingness to repeat concepts, ability to recontextualize and reword information in personalized ways, and openness to my never-ending stream of questions. Most importantly, they have encouraged us to jump in, to make mistakes, to learn from them. While they have their own expertise in the field, their own “content knowledge” of how to do these tasks themselves, they have also developed what Mitchell J. Nathan et. al in “Expert Blind Spot” describes as “pedagogical content knowledge.” The former refers to their own competence in the field, while the latter underscores their anticipation of the learning obstacles of novices and their ability to structure and teach in a way that meets the needs of learners rather than the expectations of experts (Nathan 7). They do not distinguish themselves as experts from us as students; rather, there is the acknowledgement that they, too, were once where we are (including their own humanities background), that they have merely had more time to learn and master these skills. This self-awareness allows them to recognize learning opportunities and (dare I say?) enjoy them. At our first Praxis meeting months ago, Jeremy Boggs showed us the xkcd comic, xkcd: Ten Thousands. While I thought it was a nice mindset then, I saw myself exclusively as the character with knowledge to share. I recall this comic now and it resonates more deeply with my recent experiences; I am both characters at once as long as I can embrace unrestrictedly the expertise others offer me and recognize that I can offer expertise in return. Perhaps it is impossible to do either successfully without grasping the other. Regardless, there is no doubt that I will embrace both as I move forward.

Jennifer is a 2015-2016 Makerspace Consultant and a 2014-2015 Praxis Fellow. She is a Ph.D. Candidate in the History of Art and Architecture and her research focuses on medieval architecture in Norse territories of NW Europe.


  1. Thanks for finally talking about > Novice struggles and expert blindness:
    How my discomfort with PHP will make me a better instructor |
    Scholars’ Lab < Liked it!

14 Tweets

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>