Chapter 9 Sociology: Myths about Silicon Valley and its Workers

9.1 Introduction

This module will be a little bit unique in that there is no big overarching “topic” to discuss with a problem and solutions. Rather, we will investigate myths about Silicon Valley and tech workers. In actuality, there are many, but only two will be covered in this module.

In so far as technological products are products of their environments, it is worth investigating the environment that many products are developed in and debunking common myths. It is tough to dispute that the ethos and legacy of Silicon Valley has permeated the technology sector at large; the most famous technologists, Elon Musk, Bill Gates, and Steve Jobs are all strongly tied to the myth of the Valley. Even those companies not based in Silicon Valley are undeniably influenced by it, as such, the myths about it have permeated through the country at large. They are worth investigating, and further researching.

9.2 Diversity in Tech is a “pipeline problem”

Technology has a diversity and inclusion issues. Consider Google, in it’s 2020 annual diversity report, 5.5% of employees identify as black, 6.6% identify as Latinx, and 32.5% identify as women (Chakravorti 2020). Essentially the myth goes as such, companies would love to hire more diverse candidates, but when they interview candidates, the ones that pass the interview process are disproportionately less diverse. Companies would love a more diverse environment, but they would never want to lower the bar, and the problem is in finding enough qualified candidates. If there were more qualified candidates that were graduating from top colleges, or in entry level positions then these same companies would do a better job hiring a more diverse candidate slate as a result. In 2016, Facebook’s head of diversity, Maxine Williams claimed in defense of their diversity statistics that “it has become clear that at the most fundamental level, appropriate representation in technology or any other industry will depend upon more people having the opportunity to gain necessary skills through the public education system” (Blog 2016), essentially repeating a form of the “pipeline” problem argument

This line of thinking has been heavily contested. One way in which this is untrue is that it in essence relies on a form of “credentialing.” For example, if a job requires a PhD or a Masters, then companies will recruit from the best Masters and PhD programs. However, these same programs are also biased against diverse candidates in their own manner. For starters, these programs are incredibly expensive, seemingly ruling out those who do not already have the means to afford them. In addition, these programs also require standardized testing, an indicator which is also highly correlated with wealth and social status. As described by Dr. Joy Rankin, “literally decades of research have shown SATs correlate in no way with how you’re going to do in college or how you might be as a student, but correlate everything with how wealthy your family is, which also then correlates with race and access to all other sorts of things like tutoring and etc. But that same time of credentialing pops up time and time again” (Dickey 2021). In other words, one is not necessarily hiring “better” candidates, but merely those candidates whose credentials most resemble one’s own, simply reinforcing bias back into the structure at paly.

9.3 Systems need to be maintained

In 2020 during the COVID-19 pandemic, the state of New Jersey was experiencing huge levels of distress to its state unemployment program. Those who were recently laid off couldn’t sign themselves up for unemployment, and those who could sign themselves up were experiencing massive slowdowns. The governor of the state, Phil Murphy, put out a plea for COBOL programmers. Governor Murphy pinned the issue down by pointing out that “[l]iterally, we have systems that are 40 years-plus old” (Kelly 2020). This problem was not just limited to New Jersey, and affected upwards of a dozen different states who also had unemployment programs built in COBOL (Hicks 2020). But COBOL had been made a convenient scapegoat.

COBOL was released in 1960. As described by Jean Sammet, the main architect of COBOL “was certainly intended (and expected) that the language could be used by novice programmers and read by management.” Compared to existing languages, such as FORTRAN, the intention was to “avoid idosyncratic abbrevations, and mathematical symbols that could be difficult to understand.” In fact, one COBOL programmer claimed, “You write COBOL like a novel! Anyone could follow your code.” (Hicks 2020). By 1970, it became the most popular computing language in the world. It is still taught in community colleges around the country, and there are active COBOL communities around the world today. In the words of Mar Hicks, " the majority of people in the COBOL programmers’ Facebook group are twenty-five to thirty-five-years-old, and the number of people being trained to program and maintain COBOL systems globally is only growing. Many people who work with COBOL graduated in the 1990s or 2000s and have spent most of their twenty-first century careers maintaining and programming COBOL systems."

However, this same accessibility has been denigrated and criticized. Ironically, the accessibility of COBOL has led to the language being the butt of many jokes. It is frequently called an “old, dead language.” Ironically enough, C, was released in 1972 (roughly 12 years after COBOL), and is not mocked for being called an “old, dead language.” Many trace the insults back to a form of gatekeeping, or “if your code is easy to understand, maybe you and your skills aren’t all that unique or valuable. If management thinks the tools you use and the code you write could be easily learned by anyone, you are eminently replaceable.” (Hicks 2020). This comes into play when it comes to COBOL, because “the narrative that COBOL was to blame for recent failures undoes itself: scapegoating COBOL can’t get far when the code is in fact meant to be easy to read and maintain.” (Hicks 2020).

No one is claiming that COBOL is perfect, but the fact is that any well-defined system needs resources, and investment to be maintained over time. Given enough time, even the sturdiest buildings need to be renovated from time to time so that they don’t fall into disrepair. The analogy with code is similar; it’s quite easy to scapegoat a language, but it’s important for engineers to understand that no product can simply be thrown out there and self-maintained. Rather, resources and often money need to be invested in order to maintain systems in the long run. The best engineers understand this, but in the field of government, non-technical stakeholders too often want to “build and ship it,” without thinking about the long-term investments that are required of code just like with physical engineering feats.

9.4 Resources

An article to read: https://logicmag.io/care/built-to-last/