Why the way we think matters in technology

By Faith Culas

My husband and I had bought a flatpack desk and were figuring out how to assemble it. He jumped right in, trying to fit the pieces of wood together, fiddling with the screws and Allen keys. I decided to read the manual.

Building a piece of flatpack furniture can be approached in different ways. One is not better than the other; they are just different ways of solving a problem. This is called cognitive diversity.

I am an engineer. Our job is to solve problems. How we think influences the steps and decisions we make and those decisions determine the technology we create.

But what if the technology does not reflect cognitive diversity?

One of the clearest examples comes from driving a car. Research has found that, in comparable crashes, seat-belted women have 73 percent higher odds of serious injury in frontal collisions and about a 17% higher risk of death than men.

One reason for this is that car safety standards are determined by testing with car-crash dummies. But it was not until 2022, more than 60 years after they first appeared, that a car crash dummy representing the average woman was introduced.

This was an unintended consequence of limited diversity in the design process.

As a software engineer, I wondered what impact this has on the software millions of people rely on every day. If people naturally approach problems differently, do the tools and methods in software engineering equally support all those ways of thinking?

Technologies such as facial recognition systems have performed less accurately for people with darker skin tones. AI-powered food ordering systems have struggled with different accents, resulting in incorrect orders because the data and design decisions behind these systems do not adequately represent everyone. When cognitive diversity is overlooked, technology can unintentionally disadvantage some users.

My research looks at whether software engineering tools reflect a lack of cognitive diversity and what this means for those who use software. The research involved conducting two controlled laboratory studies with more than 80 software engineering students. Participants completed realistic code comprehension tasks. At the same time, multiple sources of data were collected in one-on-one lab sessions.

One study used a think-aloud protocol, allowing me to understand how the students reasoned. The second study used an eye tracker to record where participants looked, how they searched for information, and how they navigated different parts of the code.

The studies used an established psychology framework to understand differences in cognitive styles, including how people process information, learn, perceive their own ability and assess risk.

The findings were clear. In the first study, using a tool called a debugger, students approached tasks differently. Tinkerers were able to discover features of the tool, while process-oriented learners struggled. In the second study, students searched through code differently and focused on different information. More importantly, there was evidence that some software engineering tools supported certain ways of thinking better than others.

Many software tools implicitly assume that software engineers all think the same way. When that assumption doesn’t hold, some engineers may need to work harder to achieve the same outcome. Over time, these small disadvantages may influence confidence, productivity and even who progresses into senior and decision-making roles.

The goal of this research is not to change how software engineers think. Instead, it is to understand these differences so that we can design software development tools that support the wide range of ways in which people think and solve problems.

By designing software engineering tools that better support cognitive diversity, we can help to create technology that is inclusive, not only for the engineers who build it, but also for the people who ultimately use it.