The information won’t just sink in: Helping teachers provide technology-assisted data literacy instruction in social studies

Last year, Tammy Shreiner and I published an article in the British Journal of Educational Technology, “The information won’t just sink in: Helping teachers provide technology-assisted data literacy instruction in social studies.” (I haven’t been able to blog much the last year while starting up PCAS, so please excuse my tardiness in sharing this story.) The journal version of the paper is here, and our final submitted version (not paywalled) is available here.

Tammy and I used this paper to describe what happened (mostly during the pandemic) as we continued to provide support to in-service/practicing social studies teachers to adopt data literacy instruction in their classes. Since this was a journal on educational technology, we mostly focused on two technologies:

• The OER Tammy created to support data literacy in social studies education — see link here.
• DV4L, the Data Visualization for Learning tool that we created explicitly for social studies teachers — see link here.

When we started collaborating together, we looked for a theoretical model could inform our work. The end goal was easy to describe: we wanted social studies teachers to teach data literacy. But it’s hard to measure progress towards that big, high-level goal. Teachers are teaching data literacy, or they’re not. How do you know if you’re getting closer to the goal? We structured our work and our evaluation around the Technology Acceptance Model (TAM). TAM suggests that adoption of a new technology boils down to two questions: (1) is the technology actually useful in solving a problem that users care about, and (2) is the technology usable by the users? Those were things that we could measure progress towards.

During the pandemic, we ran several on-line professional learning opportunities — a workshop where practicing teachers could try out the OER with some guidance (e.g., “Make sure you see this” and “Why don’t you try that?”), and kick the tires on a bunch of tools including DV4L. We gathered lots of data on those teachers, and Tammy did the hard work of analyzing those data over time. We made progress on TAM goals — our tools got more usable and more useful.

But we still got very little adoption. TAM didn’t work for us. Adoption didn’t increase as usability and usefulness increased.

Why not? That’s a really big question, and we barely touch on it in this paper. It’s now a couple of years since we wrote the BJET article, and I could now tick off a dozen bullet points of reasons why teachers do not adopt, despite a technology being both useful and usable. I’m not going to list them here, because there are other publications in the pipeline. Bahare Naimipour, the EER PhD student working on our project, is finishing a case study of some teachers who did adopt and how their beliefs about data literacy changed.

I can give you a big meta-reason which probably isn’t a surprise to most education researchers but might be a surprise to many computer scientists: It’s not all about (or even mostly about) the technology. I led the group that worked on DV4L, and I’ve been directing students who have been helping Tammy make the OER more usable and useful (including build new tools that we haven’t yet released). TAM matters, but the characteristics of the individual teachers and the context of the teacher’s classroom are critical factors that technology is unlikely to overcome.

---

This is work funded in part by our National Science Foundation grant, #DRL2030919

From Guided Exploration to Possible Adoption: Patterns of Pre-Service Social Studies Teacher Engagement with Programming and Non-Programming Based Learning Technology Tools

In October, Bahare Naimipour presented our paper ”From Guided Exploration to Possible Adoption: Patterns of Pre-Service Social Studies Teacher Engagement with Programming and Non-Programming Based Learning Technology Tools” (Naimipour, Guzdial, Shreiner, and Spencer, 2021) at the Society for Information Technology and Teacher Education (SITE) 2021 conference. (Draft of the paper is available here. Full paywall version available here.) This paper is the first one about our work with social studies teachers since we received NSF funding. It was also a report on our last face-to-face participatory design session (in March 2020) before the pandemic lockdown. And most importantly, it was our first session with our data visualization tool DV4L in the mix.

I have blogged about our participatory design sessions before (see Bahare’s FIE paper from last Fall). Basically, we set up a group of social studies teachers in pairs, then ask them to try out various visualization tools with activity sheets that we have created to scaffold their process. The goal is to get everyone to make a visualization successfully in less than 10 minutes, and leave time to explore or try one (or both) other tools. There is time for the pairs to persuade each other to (a) come try the cool tool they found or (b) avoid this tool because it’s too hard or not useful. The tools in this set were Vega-Lite (a declarative programming tool which our teachers have found complex but useful in the past), CODAP (a drag-and-drop visualization tool designed for middle and high school students), and our DV4L (a purpose-built visualization tool that makes code visible but not required).

The teachers saw value in having students build visualization themselves (e.g., “I think making your own data visualization allows for a deeper connection and understanding of the data.”) As we hoped, they teased out what they liked and disliked about the tools. Most of the teachers preferred DV4L over the other two tools, because of its simplicity. Critically, they felt that they were engaging with the inquiry and not the tool: “(With DV4L) I found myself asking questions connected to the data itself, rather than asking questions in order to figure out how to work the visual.”

That teachers found DV4L easier than Vega-Lite isn’t really surprising. We were pleased that teachers weren’t disappointed with DV4L’s more limited visualization capabilities. What was really surprising was that our teachers preferred DV4L to CODAP, and this has happened in successive in-service teacher participatory design sessions during the pandemic. CODAP is drag-and-drop, creates high-quality visualizations, and was designed explicitly for middle and high school students. A teacher in one of our in-service design sessions explained to me why she preferred DV4L to CODAP. “CODAP is really powerful, but it would take me at least three hours to get my students comfortable with it. Is it worth it?” Just how much visualization is any social studies teacher going to use? Again, too much focus on the tool gets in the way of the social studies inquiry.

Now you might be asking, “But Mark, do the students learn history with DV4L? And do they see and learn about computing?” Great questions — we’re not there yet. Here’s one of our big questions, after running several more participatory design sessions with teachers since the lockdown: Why aren’t teachers adopting DV4L in their classrooms? They tell us that they really like it. But nobody’s adopted yet. How do we go from “ooh, great tool!” to “and here’s my lesson plan, and we’ll use it next week”? That’s an active area of research for all of us right now.

Let’s program in social studies classes: NSF funding for our work in task-specific programming languages

If we want all students to learn computer science (CS for All), we have to go to where the students are. Unfortunately, that’s not computer science class. In most US states, less than 5% of high school students take a course in computer science.

Programming is applicable and useful in many domains today, so one answer is to use programming in science, mathematics, social studies, and other non-CS classes. We take programming to where the students are, and hope to increase their interest and knowledge about CS. I love that idea and have been working towards that goal for the last four years. But it’s a hard sell. I told the story in 2018 (see post here) about how the mathematics teachers rejected our pre-calculus course that integrated computing. How do we help non-CS teachers to see value in computing integrated into their classes?

That’s the question Tammy Shreiner at Grand Valley State and I get three years to explore, thanks to a new grant from the US National Science Foundation in the research strand of the “CS for All” Program. Tammy teaches a course on “Data Literacy for Social Studies Teachers” at GVSU, and she (with her colleague Bradford Dykes) have been building an open educational resource (OER) to support data literacy education in social studies classes. We have been working with her to build usable and useful data visualization tools for her curriculum. Through the grant, we’re going to follow her students for three years: From taking her pre-service class, out into their field experiences, and then into their first classes. At each stage, we’re going to offer mentoring and workshops to encourage teachers to use the things we’ve showed them. In addition, we’ll work on assessments to see if students are really developing skills and positive attitudes about data literacy and programming.

Just a quick glimpse into the possibilities here. AP CS Principles exam-takers are now about 25% female. AP US History is 56% female exam takers. There are fives times as many Black AP US History exam-takers as AP CSP exam-takers. It’s a factor of 14 for Hispanic students. Everyone takes history. Programming activities in a history class reach a far more diverse audience.

I have learned so much in the last couple of years about what prevents teachers from adopting curriculum and technology — it’s way more complicated than just including it in their pre-service classes. Context swamps pre-service teaching. The school the teacher goes to influences what they adopt more than what they learned pre-service. I’ve known Anne Ottenbreit-Leftwich for years for her work in growing CS education in Indiana, but just didn’t realize that she is an expert on technology adoption by teachers — I draw on her papers often now.

Here’s one early thread of this story. Bahare Naimipour, an EER PhD student working with me, is publishing a paper at FIE next month about our early participatory design sessions with pre-service social studies teachers. The two tools that teachers found most interesting were CODAP and Vega-Lite. Vega-Lite is interesting here because it really is programming, but it’s a declarative language with a JSON syntax. The teachers told us that it was powerful, flexible — and “overwhelming.” How could we create a scaffolded path into Vega-Lite?

We’ve been developing a data visualization tool explicitly designed for history inquiry (you may remember seeing it back here). We always show at least two visualizations, because historical problems start from two accounts or two pieces of data that conflict.

As you save graphs in your inquiry to the right, you’re likely going to lose track of what’s what. Click on one of them.

This is a little declarative script, in a Vega-lite-inspired JSON syntax. It’s in a task-specific programming language, but this isn’t a program you write. This is a program the describes the visualization — code as a concise way of describing process.

We now have a second version where you can edit the code, or use the pull-down menus. These are linked representations. Changing the menu changes the code and updates the graph. Changing the code updates the menu and the graph. Now the code is also malleable. Is this enough to draw students and teachers into programming? Does it make Vega-Lite less overwhelming? Does it lead to greater awareness of what programming is, and greater self-efficacy about programming tasks?

We just had our first in-service teacher workshop with these tools in August. One teacher just gushed over them. “These are so great! How did I not know that they existed before?” That’s easy — they didn’t exist six months ago! We’re building things and putting them in front of teachers for feedback as quickly as we can, in a participatory design process. We make lots of mistakes, and we’re trying to document those, too. We’re about applying an HCI process to programming experience design — UX for PX.

---

If you know a social studies teacher who would want to keep informed about our work and perhaps participate in our workshops, please have them sign up on our mailing list. Thank you!

Please forward to high school history teachers: Task-specific programming in social studies data viz

Hi,

We built this tool, DV4L (Data Visualization for Literacy), to help teachers quickly create data visualizations for social study classes. This is currently a minimum viable product (MVP) version of our tool, and we would like to collect your feedback so that we can improve! 

• Please take a few moments and try out our tool at http://b48ca06e.ngrok.io/index.html
• We intend for DV4L to be intuitive and easy to use, so you shouldn’t need any instructions to start. (If you ever see a screen with ‘TOO MANY CONNECTIONS’ on the top, please just wait for a few seconds and refresh the page.)
• After you have tried out the tool, please take a few minutes to fill out this survey at https://forms.gle/jASed4f7GfTZD9xa8. 
  

We would really appreciate it if you could do this by Sunday Dec 8th to meet our class requirements. 

Feel free to share this with any other teachers or students who would like to try this out. Thank you so much!

I have been working with a team of four University of Michigan Computer Science students (in a class with Elliot Soloway) to develop a data visualization tool for history classes. They have a prototype ready for testing, and they need user data for their class by Sunday, December 8. Could you please forward this to any high school (or middle school) history teachers you know? They would also love to get some feedback from high school history students, too.

Here are three reasons why I’m excited about this tool.

First, the team really listened to us, our history professor collaborator (Tammy Shreiner), and the social studies teachers who gave us feedback on different data visualization tools. One of the students drove 2.5 hours to attend a participatory design session with social studies teachers in October. As an example, there are driving questions for each database, to guide students in what they might inquire about — that’s a specific request from Tammy.

Second, this is a tool for history inquiry. Data visualization tools like Vega-Lite and CODAP are terrific. (Readers of this blog know how impressed I am by Vega-Lite.) But they’re not designed for inquiry. As Bob Bain has taught me, historical inquiry starts from two pieces of evidence or two accounts that disagree. This tool is designed to support comparing different pieces of evidence, and maintaining a trace of what you’ve explored. Inquiry is about comparison, not from building a single visualization.

Third, this is task-specific programming in a subtle and interesting way. You build visualizations by making choices from pull-down menus on the left. As you find interesting graphs, you save them to the right. When you want to remember what the graph is about, you hover over it and get a textual representation of what pull-down menus generated this graph. I’m arguing that hover text is a program —- it’s a representation of the process for generating that graph, and it serves as a reminder of where you’ve been. It’s a program whose value is in reading it, not executing it.

Amy Ko told me once (I’m paraphrasing) that a program is a description of a process for the future. Using a tool is for now. A program represents the future. This program could be executed by the user in the future — set the pop-up menus to the same values, and you’ll get the same visualization. More importantly, the program represents the past and serves as a reminder for what you can do next.

Please do pass this around so that our team can get a sense of what’s working and what’s not in this prototype. Thanks!

Making the Case for Adaptive Parsons problems and Task-Specific Programming: Koli Calling 2019 Preview

I am excited to be presenting at the 19th Koli Calling International Conference on Computing Education Research (see site here). Both Barbara Ericson and I have papers this year. This was my third submission to Koli, and my first acceptance. Both of us had multiple rejections from ICER this year (see my blog post on ICER), so we updated and revised based on reviews, and were thrilled to get papers into Koli.

Investigating the Affect and Effect of Adaptive Parsons Problems

By Barbara Ericson, Austin McCall, and Kathryn Cunningham.

Barb is presenting the capstone to her dissertation work on adaptive Parsons problems (see blog post on her dissertation work here). This paper captures the iterative nature of her study. Early on, she did detailed think-aloud/interview protocols with teachers to understand how people used her adaptive Parsons problems. At the end, she looked at log files to get a sense of use at scale.

Abstract: In a Parsons problem the learner places mixed-up code blocks in the correct order to solve a problem. Parsons problems can be used for both practice and assessment in programming courses. While most students correctly solve Parsons problems, some do not. Un- successful practice is not conducive to learning, leads to frustration, and lowers self-efficacy. Ericson invented two types of adaptation for Parsons problems, intra-problem and inter-problem, in order to decrease frustration and maximize learning gains. In intra-problem adaptation, if the learner is struggling, the problem can dynamically be made easier. In inter-problem adaptation, the next problem’s difficulty is modified based on the learner’s performance on the last problem. This paper reports on the first observational studies of five undergraduate students and 11 secondary teachers solving both intra-problem adaptive and non-adaptive Parsons problems. It also reports on a log file analysis with data from over 8,000 users solving non-adaptive and adaptive Parsons problems. The paper reports on teachers’ understanding of the intra-problem adaptation process, their preference for adaptive or non-adaptive Parsons problems, their perception of the usefulness of solving Parsons problems in helping them learn to fix and write similar code, and the effect of adaptation (both intra-problem and inter-problem) on problem correctness. Teachers understood most of the intra-problem adaptation process, but not all. Most teachers preferred adaptive Parsons problems and felt that solving Parsons problems helped them learn to fix and write similar code. Analysis of the log file data provided evidence that learners are nearly twice as likely to correctly solve adaptive Parsons problems than non-adaptive ones.

Task-Specific Programming Languages for Promoting Computing Integration: A Precalculus Example

By Mark Guzdial and Bahare Naimipour

This is my first paper on the work I’m publishing on the new work I’m doing in task-specific programming. I mostly discuss my first prototype (see link here) and some of what math teachers are telling me (see link here). We also include a report on Bahare’s and my work with social studies educators A good bit of this paper is putting task-specific programming in a computing education context. I see what I’m doing as pushing further microworlds.

Typically, a microworld is built on top of a general-purpose language, e.g., Logo for Papert and Boxer for diSessa. Thus, the de- signer of the microworld could assume familiarity with the syntax and semantics of the programming language, and perhaps some general programming concepts like mutable variables and control structures. The problem here is that Logo and Boxer, like any general-purpose programming language, take time to develop proficiency. A task-specific programming language (TSPL) aims to provide the same easy-to-understand operations for a microworld, but with a language designed for a particular purpose.

Here’s the abstract:

Abstract: A task-specific programming language (TSPL) is a domain-specific programming language (in programming languages terms) designed for a particular user task (in human-computer interaction terms). Users of task-specific programming are able to use the tool to complete useful tasks, without prior training, in a short enough period that one can imagine fitting it into a normal class (e.g., around 10 minutes). We are designing a set of task-specific programming languages for use in social studies and precalculus courses. Our goal is offer an alternative to more general purpose programming languages (such as Scratch or Python) for integrating computing into other disciplines. An example task-specific programming language for precalculus offers a concrete context: An image filter builder for learning basic matrix arithmetic (addition and subtraction) and matrix multiplication by a scalar. TSPLs allow us to imagine a research question which we couldn’t ask previously: How much computing might students learn if they used a multiple TSPLs in each subject in each primary and secondary school grade?

Eventually the papers are going to appear in the ACM Digital Library. I have a preprint version of Barb’s paper here, and a longer form (with bigger screenshots) of my paper here.

Social studies teachers programming, when high schools choose to teach CS, and new models of cognition and intelligence in programming: An ICER 2019 Preview

My group will be presenting two posters at ICER this year.

• Bahare Naimipour (Engineering Education Research PhD student at U-Michigan) will be presenting our participatory design session with social studies educators, Helping Social Studies Teachers to Design Learning Experiences Around Data–Participatory design for new teacher-centric programming languages. We had 18 history and economics teachers building data visualizations in either Vega-Lite or JavaScript with Google Charts. Everyone got the starter visualization running and made changes that they wanted in less than 20 minutes. Those who started in Vega-Lite also tried out the JavaScript code, but only about 1/4 of the JS groups moved to Vega-Lite successfully.
• Miranda Parker (Human-Centered Computing PhD student at Georgia Tech) will be presenting her quantitative model explaining about half of the variance in whether Georgia high schools taught CS in 2016, A Statewide Quantitative Analysis of Computer Science: What Predicts CS in Georgia Public High School. The most important factor was whether the school taught CS the year before, suggesting that overcoming inertia is a big deal — it’s easier to sustain a CS program than start one. She may talk a little about her new qualitative work, where she’s studying four schools as case studies about their factors in choosing to teach CS, or not.

Barbara is co-author on a paper, A Spaced, Interleaved Retrieval Practice Tool that is Motivating and Effective, with Iman Yeckehzaare and Paul Resnick . This is about a spaced practice tool that 32% of the students in an introductory programming course used more than they needed to, and the number of hours of use had a measurable positive effect on the final exam grade.

All of our other papers were rejected this year, but we’re in good company — the accept rate was around 18%. But I do want to talk about a set of papers that will be presented by others at ICER 2019. These are papers that I heard about, then I asked the authors for copies. I’m excited about all three of them.

How Do Students Talk About Intelligence? An Investigation of Motivation, Self-efficacy, and Mindsets in Computer Science by Jamie Gorson and Eleanor O’Rourke (see released version of the paper here)

One of the persistent questions in computing education research is why growth mindset interventions are not always effective (see blog post here). We get hard-to-interpret results. I met Jamie and Nell at the Northwestern Symposium on Computer Science and the Learning Sciences in April (amazing event, see here for more details). Nell worked with Carol Dweck during her graduate studies.

Jamie and Nell found mixed mindsets among the CS students that they studied. Some of the students they studied had growth mindsets about intelligence, but their talk about programming practices showed more fixed mindset characteristics. Other students self-identified as having some of both growth and fixed mindset beliefs.

In particular, some students talked about intelligence in CS in ways that are unproductive when it came to the practice of programming. For example, some students talked about the best programmers as being able to write the whole code in one sitting, or never getting any errors. A more growth mindset approach to programming would be evidenced by talking about building programs in pieces, expecting errors, and improving through effort over time.

This is a really helpful finding. It gives us new hypotheses to explore about why growth mindset interventions haven’t been as successful in CS as in other disciplines. Few disciplines have this strong distinction between their knowledge and their practice as acutely as we do in CS. It’s no wonder that we see these mixed mindsets.

Toward Context-Dependent Models of Productive Knowledge in Programming Cognition, by Brian A. Danielak

I’ve known Brian since he was a PhD student, and have been hoping that he’d start to publish some of his dissertation work. I got to read one chapter of it, and found it amazingly insightful. Brian explained how what we might see as a “random walk” of syntax was actually purposeful and rational behavior. I was excited to hear about this paper, and I enjoyed reading it.

It’s such an unusual paper for ICER! It’s empirical, but has no methods section. A big part of it is connecting to prior literature, but it’s not about a formal literature review.

Brian is making an argument about how we characterize knowledge and student success in CS. He points out that we often talk about students being wrong and having misconceptions, which is less productive than figuring out what they understand and where their alternative conceptions work or fail. I see his work following on to the work of Rich et al. (mentioned in this blog post) on CS learning trajectories. There are so many things to learn in CS, and sometimes, just getting started on the trajectory is a big step.

Spatial Encoding Strategy Theory: The Relationship between Spatial Skill and STEM Achievement by Lauren Margulieux.

Lauren is doing some impressive theoretical work here. She’s considering the work exploring the relationship between spatial reasoning and CS learning/performance, then constructs a theory explaining the observed results. Since it’s Lauren, the theory is thorough and covers well the known results in this space. I wrote her that I didn’t think that theory explains things that we expect are related to spatial reasoning, but we don’t yet have empirical evidence to support it. For example, when programmers simulate a program in their mind, their mental models may have a spatial component to them, but I don’t know of empirical work that explores that dimension of CS performance. But again, since it’s Lauren, I wouldn’t be surprised if her presentation addresses this point, beyond what was in the paper. (Also, read Lauren’s own summary of the paper here.)

I am looking forward to the discussion of these papers at ICER!

Computer Science Teachers as Provocateurs: All learning starts from a problem

One of the surprising benefits of working with social science educators (history and economics) has been new perspectives on my own teaching. I’ve studied education for several years, and have worked with science and mathematics education researchers in the past. It hadn’t occurred to me that history education is so different that it would give me a new way of looking at my own teaching.

Last week, I was in a research meeting with Bob Bain, a history and education professor here at U. Michigan. He was describing how historians understand knowledge and what historian’s practice looks like, and how that should be reflected in the history classroom.

He said that all learning in history starts from a problem. That gave me pause. What’s a “problem” in history?

Bob explained that he defines problem as John Dewey did, as something that disturbs the equilibrium. “Activities at the Dewey School arose from the child’s own interests and from the need to solve problems that aroused the child’s curiosity and that led to creative solutions.” We don’t think until our environment is disturbed, but that environment may just be in your own head.

We each have our own stories that we use to explain the world, and these make up our own personal equilibria. Maybe students have always been told that the American Civil War was about states’ rights, and then they read the Georgia Declaration of Secession. Maybe they’ve thought of Columbus as the explorer who discovered America, and then note that he wasn’t celebrated until 1792, 300 years after his arrival. Why wasn’t he celebrated earlier, and why him and at that time? A good history teacher sets up these conflicts, disequilibria, or problems. Bob says it can be easy enough to create, simply by showing two contrasting accounts of the same historical event.

Research in the learning sciences supports this definition of learning. Roger Schank talked about the importance of learning through “expectation failure.” You learn when you realize that you don’t know something:

The understanding cycle – expectation failure – explanation – reminding – generalization – is a natural one. No one teaches it to us. We are not taught to have goals, nor to attempt to develop plans to achieve those goals by adapting old plans from similar situations. We need not be taught this because the process is so basic to what comprises intelligence. Learning is a natural act.

In progressive education, we’re told that the teacher should be a “Guide on the Side, not the Sage on the Stage.” When Janet Kolodner was developing Learning By Design, she talked about the role of teacher as coach and orchestrator. Those were roles I was familiar with. Bob was describing a different role.

I challenged him explicitly, “You’re a provocateur. You create the problems in the students’ minds.” He agreed.

Bob got me thinking about the role of the teacher in the computer science class. We can sometimes be a guide, a coach, and orchestrator — when students are working away on some problem or project. But sometimes, we have to be the provocateur.

We should always start from a problem. In science education, this is easy. Kids naturally do wonder why the sky is blue, why sunsets are more red, why heat travels along metal but not wood, and why stars twinkle. In more advanced computer science, we can also start from questions that students’ already have. I’m taking a MOOC right now because it explains things I’ve wondered about.

But in introductory classes, students already use a computer without problems. They may not see enough of real computing to wonder about how it works. The teacher has to generate a problem, inculcate curiosity — be a provocateur.

We should only teach something when it solves a problem for the student. A lecture on variables and types should be motivated by a problem that the variables and types solve. A lecture on loops should happen when students need to do something so often that copy-pasting the code repeatedly won’t work. Saying “You’re going to need this later” is not motivation enough — that doesn’t match the cycle that Schank described as natural. Nobody remembers things they will need in the future. Learning results when you need new knowledge to resolve the current problem, disequilibria, or conflict.

Note: Computer science doesn’t teach problem-solving. Dewey’s and Schank’s point is that problem-solving is a natural way in which people learn. Learning to program still doesn’t teach problem-solving skills.

Is the IT field more nasty than others?

The main point of the piece quoted below is important and is something I struggle with.  By doing something different for women in IT than men in IT, are we ghettoizing women?  Are we making them feel awkward by trying to make them feel welcome?  I tend to think of what we do at Georgia Tech is being like curb cuts that try to make things better for everyone, but I see the concern.

The particular point that I’m quoting raises an empirical question for me.  Is the IT field more nasty than others?  The author states that getting hyper-critical comments is common “in any career in the adult workforce.”  I’m not sure that’s true.  Jeannette  Wing has written about how CS reviews at NSF are much more negative than other disciplines.  In my own experience, I’ve seen a marked difference.  I’ve mostly worked in the commercial IT industry, and in academic computing.  But I also earned part of my doctorate in a School of Education, and I’ve spent a good bit of time in schools.  Education is not nearly as nasty and mean as IT.  I would be interested in seeing some empirical studies.  I suspect that there is far more nasty (e.g., swearing and name-calling) criticism in IT than in other fields.  That nastiness does create a barrier for lots of people, but especially for people who notice that they’re in the under-represented group.

But tech is a highly competitive field with a high concentration of very smart, frequently socially awkward people. Some of them are going to shit on you because they think you’re not as smart as them. I promise you that they will shit on you for that regardless of your gender. Sometimes they may use your gender as ammunition because it’s the easy target, but make no mistake – they would still have made you feel badly if you were a guy, they just would have picked something else to fling at you that would cut as deeply.

Sometimes they’re not even socially awkward – they’re just assholes.

If you want to get into tech — or any career in the adult workforce, really — you have to be prepared for people like that sometimes. Tech isn’t some magical haven with a big bouncer at the door that doesn’t let any assholes in. We have them, and so does every other industry on the planet. You probably have friends or family who are assholes. They’re everywhere. Sometimes when a male higher-up than you steals your idea and presents it as their own, it’s because they’re self-serving douchebags, not because you’re female. They’d have done the same to a male co-worker, too.

via Thoughts on GitHub Giving Free Private Repos to Women | Snipe.Net.