Category: technology strategy

The Expert Blind Spot

~ cjois

Wiggins and McTighe describe the “Expert Blind Spot” in Chapter 2 and how it could impact greater student understanding. On page 46 they describe three types of “uncovering” that assist in designing and teaching for understanding to avoid forgetfulness, misconception, and lack of transfer. Select one of the ideas presented below and expand on how you could incorporate it into your current profession.

1) Uncovering student’s potential misunderstandings (through focused questions, feedback, and diagnostic assessment)

2) Uncovering the questions, issues, assumptions, and gray areas lurking underneath the black and white of surface accounts

3) Uncovering the core ideas at the heart of understanding a subject, ideas that are not obvious—and perhaps counterintuitive or baffling to the novice

While all of these are important and perhaps all required to varying proportions, I will be choosing the item (3) pertaining to uncovering core ideas.

The ‘Expert Blind Spot’ is something most people have either demonstrated or experienced. Beginning with getting instructions to make a certain recipe, driving directions, operating instructions for a device, or a lecture on how to seek happiness, most people have been subject to this form of the blind spot.

Phelan (2021) provides an example of the recipe ‘Blind Spot’.

I was teaching a class yesterday (my first session with those students) and after about 20 minutes into the class, I asked a few questions to gauge how much they knew or understand the task at hand. The result – Two students in the entire class knew the objective of the class they had registered for. The rest had no idea. Knowing that made it easy for me. I had a baseline to operate from.

I was in a conversation earlier this week about the concept of situational awareness in aviation. Upon reading a reasonable number of prior studies and results, I was slowly but surely arriving at the conclusion that situational awareness, at its core, was about perception – a human trait. Regardless of whether the individual applies it to flying or driving or waiting at a lonely bus stop, the need for being aware of your surroundings was fulfilled by the same trait, perception. In the above-mentioned conversation, the individual I was speaking to added another term – sensation. Sensing and perceiving became the core concepts of being situationally aware.

Likewise, in my profession both as a Technology Executive and as an Aviation faculty member, I realize that breaking topics down to their core ideas has been the only effective way to transfer knowledge or skill. The success of any individual who has a role to transfer knowledge or skill, in my opinion, lies entirely in how well that individual performs point (3) – i.e. breaks down topics to their core ideas – which are most often easier to communicate and entrench in a learner’s mind.

Here is an example – In teaching Project Management, one arrives at the topic of Earned Value. Earning value to novices may mean many different things. Speaking about measures such as SPI and CPI may make the instructor look really experienced and intelligent. However, it will do little to help a novice understand the subject of earning value. Instead, speaking about a project that is scoped to build the four sides of a fence, 1000 dollars for each side and four weeks to do it, frame the idea a little better.

Speaking of scenarios where the first side got built in the planned one week, and 1000 dollars was spent as planned. The project has ‘earned planned value’ for the 1000 dollars spent and 1 week elapsed. The second week went by and only half of side 2 was built and 1000 dollars was spent. The 1000 dollars failed to earn planned value and the project is now also behind schedule. Week 3 completed the remaining half of side 2 and also side 3, but only 500 dollars was spent. Time has been recovered and since the 3 sides are now complete and only 2500 dollars have been spent, they are ahead on earning planned value…. and so forth. Rarely do PMs or PM instructors teach EV in this manner.

Another way to establish and reinforce core ideas is to gravitate to workshops where students learn by doing rather than rote learning a concept.

Points (1) and (2) are equally important because they help gauge the learner and also adapt as needed to the varying needs of each learner (a concept that today has been marketed as ‘Adaptive Learning’).

References –

Huang, E. (2018). Rearview mirrors for the “expert blind spot”. Design Research in Education: A Practical Guide for Early Career Researchers, 16.

Nathan, M. J., Koedinger, K. R., & Alibali, M. W. (2001, August). Expert blind spot: When content knowledge eclipses pedagogical content knowledge. In Proceedings of the third international conference on cognitive science (Vol. 644648).

Phelan, J. (2021, March 26). Beware the Expert Blind Spot – Educate. – Medium. Medium; Educate. https://medium.com/educate-pub/beware-the-expert-blind-spot-42744dc66ba9Links to an external site.

The push for No-Code software

~ cjois

About 3 decades ago, there was a time when the business world pursued the automation of software engineering work. It was believed that computers could be used to automate the development of very software that would run computers. CASE – computer aided software engineering – was invested into, attempted in multiple ways. Millions of hours were invested into making it a reality. Those in the industry know where that went

We are back to it again… we just call it fancier name now – ‘No Code’ software. I firmly believe that software engineering must be simplified. Software is pervasive today. There is hardly an area of human life that software does not touch. It’s absolutely imperative that it become a whole lot easier to manage the engineering and subsequent maintenance of software.

Software is basically code. Code that tells computing resources what to do. So there is no such thing as ‘no-code’. Yes, we may aspire for the day that humans wont write the code or wont be writing as much code as in the past. However the more pervasive and extensively software is used, the lesser the chance that no-code will be a reality. Less code on the other hand is a better aspiration.

The software industry has struggled to even realize the benefits of software re-use yet. A simple assessment of a small sample of firms using software or building software will indicate that there are engineering teams still writing their own exception handlers, notification mechanisms. There is constant push needed even today to uphold the principles of object orientation and procedural programming. A significant majority of the software engineering still occurs by accident. The situations where engineering tools, stack components, patterns are chosen through thinking and deliberation are far and few. There is a lack of discipline and respect for software lifecycle models and associated artifacts. When reuse at the most basic levels is missing within teams, let alone within groups or organizations seeking rationalization of the practices at an industry level is perhaps asking for too much.

It is also surprising that this perhaps is the only industry where there is a drive to commodify a specialized engineering skillset (albeit that not too many in the industry may represent an engineering approach to software creation) into ‘nothingness’, and undermine the critical value of the engineering lifecycle. In no other industry has this happened in the past. No one ever says that we allow the car buyer to manufacture her/his own car or allow a smartphone user to build their own smartphone or allow the local community to build their bridge or lay their own electrical lines or sewers. It is mind-bogging that this notion lets allow users to build their own software. It’s one thing to increase user participation in the development of systems that serve them. Thats what ‘agile’ as a process is meant to do. The reality – agile has done little or nothing to help with it. The more the industry has spoken of agile, the fewer the outcomes that have resulted. In fact, it’s found that the higher the use of an agile mindset’ the lesser the discipline in building ‘production strength’ software. Another reality – users really have not enough time to dedicate themselves into the daily stand-ups and frequent exchange of software developed. They have full-time jobs.

Users are having difficulty using software that has been developed. Some may attribute that to the fact that ‘elite professionals’ sitting in the backroom called technology dev or IT do not understand what the users are asking for or how they will use it. Indeed it may be somewhat attributable to that. But the answer to that problem is not to say that we push the entire onus of engineering systems to the users. As it is the supposed ease of acquiring so called ‘cloud based capabilities’ brought about an era where business users were buying systems, applications, components at their will because software vendors were now knocking on their door instead of approach technology departments. The sale may been easier. However what that led to was a whole bunch isolated software systems that were islands in themselves. No external software vendor understands an organization’s entire software portfolio and can find methods to seamlessly integrate their new introduction into the existing ecosystem. They have to rely on internal software teams or departments for that help. Some can call it an elite group that holds the keys to the ecosystem, but what is new about that. Doesn’t finance hold the keys to the books of the company?, Doesn’t marketing do the same for lead generation?, doesn’t operations do the same. Nowhere does anyone ever speak about pushing those responsibilities out to the hands of users.

In summarizing, this comes down the distinction between giving the users the ability to plug their appliance into a wall socket versus letting them build their generation station. Looked at another way, we aren’t even sure how many users (i am sure there are some) want to build their own systems and sustain them.

Building and managing ‘production strength’ systems or the infrastructure beneath them is no small task. It is very inspiring to speak about no-code software and I am not saying that someday this wont be reality. However, it’s important to remain realistic about whats possible today given precedence and current context.

CJ