Gender Differences In Learning Style Specific To Science, Technology, Engineering And Math – Stem

There are gender differences in learning styles specific to science, math, engineering and technology (STEM) that teachers of these subjects should keep in mind when developing lesson plans and teaching in the classroom. First, overall, girls have much less experience in the hands-on application of learning principles in lab settings than boys. This could occur in the computer lab, the science lab, or the auto lab – the principle is the same for all of these settings – it requires an overall technology problem-solving schema, accompanied by use and manipulation of tools, and spatial relation skills that very few girls bring with them to the classroom on day one in comparison to boys.

Let’s look at some of the reasons why girls come to the STEM classroom with less of the core skills needed for success in this subject area. Overall, girls and boys play with different kinds of games in early childhood that provide different types of learning experiences. Most girls play games that emphasize relationships (i.e., playing house, playing with dolls) or creativity (i.e., drawing, painting). In contrast, boys play computer and video games or games that emphasize building (i.e., LEGO®), both of which develop problem-solving, spatial-relationship and hands-on skills.

A study of gender differences in spatial relations skills of engineering students in the U.S. and Brazil found that there was a large disparity between the skills of female and male students. These studies attributed female student’s lesser skills set to two statistically significant factors: 1) less experience playing with building toys and 2) having taken less drafting courses prior to the engineering program. Spatial relations skills are critical to engineering. A gender study of computer science majors at Carnegie-Mellon University (one of the preeminent computer science programs in the country) found that, overall, male students come equipped with much better computer skills than female students. This equips male students with a considerable advantage in the classroom and could impact the confidence of female students.

Are these gender differences nature or nurture? There is considerable evidence that they are nurture. Studies show that most leading computer and video games appeal to male interests and have predominantly male characters and themes, thus it is not surprising that girls are much less interested in playing them. A study of computer games by Children Now found that 17% of the games have female characters and of these, 50% are either props, they tend to faint, have high-pitched voices, and are highly sexualized.

There are a number of studies that suggest that when girls and women are provided with the building blocks they need to succeed in STEM they will do as well if not better than their male counterparts. An Introductory Engineering Robotics class found that while males did somewhat better on the pre-test than females, females did as well as the males on the post-test following the class’s completion.

Another critical area of gender difference that teachers of STEM should keep in mind has less to do with actual skills and experience and more to do with perceptions and confidence. For females, confidence is a predictor of success in the STEM classroom. They are much less likely to retain interest if they feel they are incapable of mastering the material. Unfortunately, two factors work against female confidence level: 1) most girls will actually have less experience with STEM course content than their male counterparts and 2) males tend to overplay their accomplishments while females minimize their own. A study done of Carnegie Mellon Computer Science PhD students found that even when male and female students were doing equally well grade wise, female students reported feeling less comfortable. Fifty-three percent of males rated themselves as “highly prepared” in contrast to 0% of females.

It is important to note that many of the learning style differences described above are not strictly gender-based. They are instead based on differences of students with a background in STEM, problem-solving, and hands-on skills learned from childhood play and life experience and those who haven’t had the same type of exposure. A review of the literature on minority students and STEM finds that students of color are less likely to have the STEM background experiences and thus are missing many of the same STEM building blocks as girls and have the same lack of confidence. Many of the STEM curriculum and pedagogy solutions that work for female students will also work for students of color for this reason.

Bridge Classes/Modules to Ensure Core Skills

Teachers will likely see a gap in the core STEM skills of female and minority students for the reasons described above. Below are some solutions applied elsewhere to ensure that girls and women (and students of color) will get the building block STEM skills that many will be missing.

Teachers in the Cisco Academy Gender Initiative study assessed the skill levels of each of their students and then provided them with individualized lesson plans to ensure their success that ran parallel to the class assignments. Other teachers taught key skills not included in the curriculum at the beginning of the course, such as calculating math integers and tool identification and use. Students were provided with additional lab time, staffed by a female teaching assistant, knowing that the female students would disproportionately benefit from additional hands-on experience.

Carnegie-Mellon University came to view their curriculum as a continuum, with students entering at different points based on their background and experience. Carnegie-Mellon’s new frame of a “continuum” is purposefully different than the traditional negative model in which classes start with a high bar that necessitates “remedial” tutoring for students with less experience, stigmatizing them and undermining their confidence. Below is a list of ideas and suggestions that will help ALL students to succeed in the STEM classroom.

1. Building Confidence

How do teachers build confidence in female students who often have less experience than their male counterparts and perceive they are behind even when they are not?

1) Practice-based experience and research has shown that ensuring female students have the opportunity to gain experience with STEM, in a supportive environment, will increase their confidence level.

2) Bringing in female role models that have been successful in the STEM field is another important parallel strategy that should be used to assist your female students in seeing themselves as capable of mastering STEM classes: if she could do it, then I can too!

3) Consistent positive reinforcement by STEM teachers of their female students, with a positive expectation of outcome, will assist them in hanging in there during those difficult beginning weeks when they have not yet developed a technology schema or hands-on proficiency and everything they undertake seems like a huge challenge.

2. Appealing to Female Interests

Many of the typical STEM activities for the classroom appeal to male interests and turn off girls. For example, curriculum in robots often involves monsters that explode or cars that go fast. “Roboeducators” observed that robots involved in performance art or are characterized as animals are more appealing to girls. Engineering activities can be about how a hair dryer works or designing a playground for those with disabilities as well as about building bridges. Teachers should consider using all types of examples when they are teaching and incorporating activities in efforts to appeal female and male interests. Teachers can also direct students to come up with their own projects as a way of ensuring girls can work in an area of significance to them.

Research also shows that there are Mars/Venus differences between the genders and how each engages in technology. Overall, girls and women are excited by how the technology will be used – its application and context. Men will discuss how big the hard drive or engine is, how fast the processor runs, and debate the merits of one motherboard or engine versus another. These are topics that are, overall, of less interest to most females.

The Carnegie-Mellon Study took into account the differences of what engages female students and modified the Computer Science programs’ curriculum so that the context for the program was taught much earlier on in the semester and moved some of the more technical aspects of the curriculum (such as coding) to later in the semester. Authors observed that the female students were much more positive about getting through the tedious coding classes when they understood the purpose of it. Teachers should ensure that the context for the technology they are teaching is addressed early on in the semester by using real world stories and case studies to capture the interest of all of their students.

3. Group Dynamics in the Classroom

Research studies by American Association of University Women and Children Now have found that most females prefer collaboration and not competition in the classroom. Conversely, most males greatly enjoy competition as a method of learning and play. Many hands-on activities in technology classes are set up as competitions. Robotics for example, regularly uses competitiveness as a methodology of teaching. Teachers should

be cognizant of the preference of many girls for collaborative work and should add-in these types of exercises to their classes. Some ways to do this are by having students work in assigned pairs or teams and having a team grade as well as an individual grade. (See Reading 2 on Cooperative Learning.)

Another Mars/Venus dynamic that STEM teachers should be aware of occurs in the lab there male students will usually dominate the equipment and females will take notes or simply watch. Overall, male students have more experience and thus confidence with hands-on lab equipment than their female counterparts. Teachers should create situations to ensure that their female students are spending an equal amount of time in hands-on activities. Some approaches have been: 1) to pair the female students only with each other during labs in the beginning of the class semester so that they get the hands-on time and their confidence increases, putting them in a better position to work effectively with the male students later on, 2) allot a specific time for each student in pair to use the lab equipment and announce when it’s time to switch and monitor this, and 3) provide feedback to male students who are taking over by letting them know that their partner needs to do the activity as well.

4. Moving Female Students from Passive Learners to Proactive Problem Solvers

The main skill in STEM is problem solving in hands-on lab situations. For reasons already discussed regarding a lack of experience, most girls don’t come to STEM classes with these problem-solving skills. Instead, girls often want to be shown how to do things, repeatedly, rather than experimenting in a lab setting to get to the answer. Adding to this issue, many girls fear that they will break the equipment. In contrast, male students will often jump in and manipulate the equipment before being given any instructions by their teacher. Teachers can address this by such activities as: 1) having them take apart old equipment and put it together again, 2) creating “scavenger hunt” exercises that force them to navigate through menus, and 3) emphasizing that they are learning the problem solving process and that this is equally important to learning the content of the lesson and insisting that they figure out hands-on exercises on their own.

Research has also shown that females tend to engage in STEM activities in a rote, smaller picture way while males use higher order thinking skills to understand the bigger picture and the relationship between the parts. Again, moving female students (and the non-techsavvy student in general) to become problem solvers (versus just understanding the content piece of the STEM puzzle) will move them to use higher order thinking skills in STEM.

Finally, many teachers have reported that many female students will often want to understand how everything relates to each other before they move into action in the lab or move through a lesson plan to complete a specific activity. The female students try to avoid making mistakes along the way and will not only want to read the documentation needed for the lesson, they will often want to read the entire manual before taking any action. In contrast, the male student often needs to be convinced to look at the documentation at all. Boys are not as concerned with making a mistake a long the way as long as what they do ultimately works. The disadvantage for female students is that they often are so worried about understanding the whole picture that they don’t move onto the hands-on activity or they don’t do it in a timely fashion, so that they are consistently the last ones in the class to finish. Teachers can assist female (and non-tech-savvy) students to move through class material more quickly by providing instruction on how to quickly scan for only the necessary information needed to complete an assignment.

5. Role Models

Since the numbers of women in STEM are still small, girls have very few opportunities to see female role models solving science, technology, engineering or math problems. Teachers should bring female role models into the classroom as guest speakers or teachers, or visit them on industry tours, to send the message to girls that they can succeed in the STEM classroom and careers.

Bibliography

Medina, Afonso, Celso, Helena B.P. Gerson, and Sheryl A. Sorby. “Identifying Gender Differences in the 3-D Visualization Skills of Engineering Students in Brazil and in the United States”. International Network for Engineering Eucation and Research page. 2 August 2004: [http://www.ineer.org/Events/ICEE/papers/193.pdf].

Milto, Elissa, Chris Rogers, and Merredith Portsmore. “Gender Differences in Confidence Levels, Group Interactions, and Feelings about Competition in an Introductory Robotics Course”. American Society for Engineering Education page. 8 July 2004: [http://fie.engrng.pitt.edu/fie2002/papers/1597.pdf].

“Fair Play: Violence, Gender and Race in Video Games 2001”. Children Now page. 19 August 2004: [http://www.childrennow.org/media/video-games/2001/].

“Girls and Gaming: Gender and Video Game Marketing, 2000”. Children Now page. 17 June 2004: [http://www.childrennow.org/media/medianow/mnwinter2001.html].

Tech-Savvy: Educating Girls in the New Computer Age. District of Columbia: American Association of University Women Educational Foundation, 2000.

Margolis, Jane and Allan Fisher. Unlocking the Computer Clubhouse: Women in Computer. Cambridge, MA: The MIT Press, 2003.

Taglia, Dan and Kenneth Berry. “Girls in Robotics”. Online Posting. 16 September 2004: http://groups.yahoo.com/group/roboeducators/.

“Cisco Gender Initiative”. Cisco Learning Institute. 30 July 2004: [http://gender.ciscolearning.org/Strategies/Strategies_by_Type/Index.html].

Why Software Engineering Isn’t Like Other Engineering Disciplines and How it Changes the Game

It has been estimated that there are over 11 million professional software developers world-wide as of 2014. When I started as a programmer in 1973 one of the greybeards in the first company I worked for gave me some advice. He said, “Learn the things that never change.”

When I started college six years earlier in 1967 the school I attended didn’t have a major called Computer Science and so I did my undergraduate and graduate work in Mathematics taking a few computer programming courses along the way. This was the way many of us got started as software developers back in the 70’s.

The term Software Engineering was new at the time, being coined at the 1968 NATO Software Engineering Conference. The thinking back then was that we needed to apply existing engineering methods to software development to address common budget, schedule and quality problems that were being referred to at the time as the “software crisis.” As a result, what most people have come to think of as Software Engineering involves activities which greatly resemble other engineering disciplines including civil, mechanical, and electrical engineering.

On the surface this idea seems to make sense. When you build something using the other engineering disciplines (e.g. a bridge, a building, a specialized piece of hardware, an electrical circuit board) you need to figure out the requirements, design a solution, implement it, and test it. All of these steps make sense for software as well. So one could certainly argue from this perspective that software engineering should resemble these other engineering disciplines. However, when you look more closely at what we have learned about software development over the last forty years, as well as how we teach it to today’s software developers, this analogy quickly breaks down.

By the time the 1990’s rolled around, because computer programming had become such a big part of what was called Computer Science, many Universities had added a course with a title of “Software Engineering” to their Computer Science curriculum. Popular textbooks that were used at that time to teach these courses included Ian Sommerville’s textbook titled: “Software Engineering”. From 1992 to 1994 I used the Fourth Edition of this textbook to teach Software Engineering at Binghamton University. Today, Ian Sommerville’s textbook is still in use in many Universities around the world-now in its Ninth Edition. This leads to a question:

Why do we need to revise a textbook approximately every 3-4 years that supposedly is teaching our students the fundamentals of Software Engineering?

If you look at textbooks used in Civil Engineering, Mechanical Engineering, and Electrical Engineering the vast majority of these books do not require revisions nearly so often. To understand why this is the case we need to look more closely at what is being taught in most Universities around the world under the name of “Software Engineering.”

When you do look more closely you will find that we are teaching our next generation of software professionals whatever is currently popular in terms of software practices, and methods. Popular software practices and methods today are known by buzzwords such as Agile, Use Cases, User Stories, RUP, XP, Scrum Lean, PSP, TSP and the list goes on and on…

The problem with this approach to teaching Software Engineering is that software practices and methods frequently come and go and will continue to come and go which is why Sommerville must continually update his textbook. This leads to another question:

What about that greybeard in the first company I worked for in 1973 who told me to learn the things that never change? Did he give me bad advice? If not, what are we teaching our next generation of software professionals with respect to the things that never change about Software Engineering?

Before answering these questions, let’s first step back and ask a few different questions:

Does a set of things that never change in Software Engineering actually exist?

If they do exist, do we know what they are?

If we do know what they are, are we teaching them in a consistent way to our next generation of software professionals so when they come out of the University they are prepared to conduct themselves as software professionals?

Such a set of software engineering essentials does in fact exist. This belief has motivated an international group of volunteers to take on the task of codifying those essentials. The intent is for these essentials to be taught to our next generation of software developers helping to prepare them as true software professionals.

The volunteers involved in this initiative (known as SEMAT – Software Engineering Method and Theory) have been working on this task since 2010. This past year SEMAT achieved a major milestone with the announcement by the Object Management Group, an international standards consortium, that they have adopted “Essence” as an official OMG standard.

So this leads to a few more questions:

Just how different is the Essence standard from what is being taught to our software developers today, and has been taught for the past 40 years under the name of Software Engineering?

And:

Will the differences really help with the problems that many believe still plague the software industry with respect to common budget, and schedule over-runs and poor software quality?

From one perspective what Essence captures is not new. The Essence standard includes common words such as, Stakeholders, Opportunity, Requirements, Software System, Team, Work, and Way of Working. But from another perspective what Essence captures is dramatically new. In fact, some are calling it a “paradigm shift” that many of the “old guard” will have great difficulty even comprehending.

To give you an idea of the changes involved when using Essence I again think back to my early days as a programmer in the late 1970’s. In those days I worked in the flight simulation domain developing software systems to train pilots to fly high performance aircrafts. One of my areas of expertise was writing software to provide record/playback capabilities to help instructors train young aircraft pilots in flying skills.

I recall one specific project I worked on and a customer pilot instructor I worked with. After explaining to him how he could use my record/playback software to help him demonstrate to his student pilots where they had made mistakes, he excitedly wrote up a number of defects requesting changes to my software.

I argued vehemently with my program manager that none of these issues were actually defects. Because I had taken the time to explain what was possible with my record/playback software the pilot instructor began to envision additional features that could make his job easier. He wrote his ideas up on a defect form even though they were all enhanced capabilities we never planned to deliver and were not part of the requirements.

But my project manager didn’t want to discuss with the customer whether or not these requests were in-scope, or out-of-scope. His view was– as many viewed software then and still view it today– that it is easier to change software than engaging the customer in a discussion.

Because software is soft, we tend to view it as easy to change. It’s not like hardware. Metal isn’t easily bent. This perspective changes the whole game when it comes to software.

This ability to change software code quickly and in endless ways completely changes the dynamics that exist between software developers and their stakeholders including program managers and customers. One way this difference exemplifies itself is as users become familiar with the software they often see new ways that changes to the software could make their job easier as my pilot instructor customer did back in the late 1970s.

We now know from experiences that there are other dimensions to Software Engineering that are critical to effective professional software engineering practices. These other dimensions take us beyond just the ease with which the code can be changed. To date, these additional dimensions have not received anywhere near the attention they deserve.

When you change code you may also be affecting the requirements, and you may also be affecting other capabilities in the software system previously tested. Changing code means additional work, additional testing, possibly changes to supporting user manuals and so on… All this affects budget and schedule, and introduces additional risk to the quality of the software.

While on the one hand the ability to change the software code rapidly brings great power to the software industry, it also means that software professionals must be increasingly attune to their agreed way of working, the impact and time that it takes to do the additional work, and the risk when making unplanned rapid changes. The agile movement over the last ten years has provided a great service to help the software community understand this major difference related to Software Engineering including the importance of early and ongoing interaction with stakeholders and the importance of software developers estimating the cost of their own work.

While the software engineering community has learned a great deal from the other engineering disciplines, they have also learned the critical importance of these other dimensions that bring differences from previous engineering experiences. These differences mean that software developers need to be trained in new and different ways to be effective software professionals.

Shortly after the kickoff of the SEMAT initiative in March of 2010, one of SEMAT’s initial signatories sent me a draft copy of a book he was working on to review. Watts Humphrey who had planned to be very active in the early SEMAT work fell ill just as the SEMAT work was gearing up and I was asked to help him get his planned effort going. In late August that same year Watts sent me the following email just a few months before his passing. He agreed that I could share this email with others:

Paul, From your comments, it sounds as if you did get the point of my book, for which I am grateful….the correct answer and the one that I was most interested in pursuing with SEMAT, concerns how we can ensure that software professionals are properly trained and have a suitable set of professional attitudes and skills before they even get to industry. It is my hope that the SEMAT effort eventually will be able to spearhead the drive to get the academic community to refocus their programs on teaching software professionals to act like professionals and to manage themselves.

When they do, their graduates will be able to negotiate with their management and to do superior work…. That is what professionals should do… A good start in this direction would be to convince them of the necessity of having software people measure their own work. Since software work is, as we said, knowledge work, any truly accurate measures must be taken by the software professionals themselves. …Watts Humphrey

Watts Humphrey has been referred to as the father of software quality. After completing a distinguished career at IBM he went on to become a fellow of the Software Engineering Institute founding the Software Process Program. In 2003 he was awarded the National Medal of Technology.

Today Watts would have been heartened by the SEMAT work that is going on in the academic community. The first full University course based on the new Essence standard has been developed and is being delivered to students this year by Dr. Carlos Zapata at the Universidad Nacional de Columbia in Medellin, Columbia, and Essence is being used in first- and second-year software engineering courses at KTH Royal Institute of Technology in Sweden under the guidance of Dr. Mira Kajko-Mattson. There have also been Essence field studies conducted with students by Dr. Cecile Peraire at Carnegie-Mellon West in the United States. The next step for the SEMAT community is to demonstrate how Essence can help in industry by publishing case studies of actual use and measured results on industrial projects.