Introduction

Within the STEM community, it’s fairly common to see people hold their education as more important than people who study humanities. These “STEM Majors” have an aura of superiority to them, asserting that their classes are the hardest, and making sure everyone around them knows. You’ve probably seen memes like the one below mocking non STEM majors, and the one below that mocking STEM majors who mock non STEM majors.

It’s also common to assume that for jobs such as software engineering, the hard technical skills are the most important, and to be competitive at your job you should focus on taking the hardest STEM classes you possibly can. Some technical schools double down on this ideology by making their CS students take classes in physics and chemistry in addition to math an CS, just to instill a hardcore engineering mindset into their students. Even if schools do not require students to be rigorously involved in computer science, students in STEM and computer science often self select to take more CS classes over classes in other departments. Presumably, they do this because they think the hard science classes will improve their skills, they will impress recruiters and tech companies, and that the humanities classes will be a waste of time and tuition money.

In this blog post, I will argue the opposite really, that the “soft skills” that come from the humanities are incredibly important, if not essential to being a good software engineer. Many people believe that software engineering is a strictly hard skill, and your success as a software engineer will come from how good of a coder you are. This is even used as an excuse to claim that women are less likely to go into software engineering, since they are more focused on “communication” and “people skills”. However, my experience as a software engineer at Google/YouTube has shown me the complete opposite: the most successful software engineers are the ones who can successfully communicate their ideas to a larger audience, and understand the larger scope of their work (including when their work is ethical). I talk to a lot of students about software engineering careers, and it always blows their minds when I tell them this, so I’m hoping by the end of this post to convince you that people with these soft skills are very needed in tech, and we should be focusing on these skills. I’ll be focusing on software engineering in specific since that’s what I do, but many of these points apply to other STEM fields as well. I’ll also be talking a lot about YouTube/Google, but only because that’s where I work, and I’m speaking mostly from my own experience.

What are the Humanities

Before talking about why they’re important, it’s probably good to have a good definition of “the humanities.” Here is one from the Stanford Humanities Center:

The humanities can be described as the study of how people process and document the human experience. Since humans have been able, we have used philosophy, literature, religion, art, music, history and language to understand and record our world. These modes of expression have become some of the subjects that traditionally fall under the humanities umbrella. Knowledge of these records of human experience gives us the opportunity to feel a sense of connection to those who have come before us, as well as to our contemporaries.

So basically, the humanities is study of fields which relate to the human experience, but in a more subjective way than something like math or science. Classes in these fields generally revolve around reading books or historical documents, listening to music, watching films, and digesting many other mediums to try to understand the subject matter at hand. The subject could be as broad as “World Music”, or as narrow as “The 18th Century French Court.” As opposed to strict testing, many classes in the humanities instead focus on essay writing and idea communication, to see how well students can form and communicate arguments about the subject matter at hand. Often these assessments are much more subjective than the ones in STEM classes, where there aren’t clear “right” or “wrong” answers, but rather you are judged on how well researched and how well argued your arguments are. The classes will also feature many class discussions and student lead presentations on their independent research, which from my experience are much less common in STEM classes. If done right, these classes teach students how to reason about their subject material in a holistic way, and communicate their ideas about the subject matter orally and in writing.

I know that these classes are considered social sciences, but I will be adding topics such as Psychology, Sociology, Economics, and History to my argument as well. These subjects provide many of the same benefits described above - providing students with the ability to reason about the larger world and humanity, as well as offering many opprounities to write essays and other similar assessments.

My Background

Also before I begin explaining my argument, I just wanted to share a bit about my background, since it’s always good to see where people come from before listening to them!

I come from a unique position - my education at Brandeis University was a bit different than what most people seemed to get for computer science. While other schools have fairly intense requirements for CS majors to take science, math, and hardcore CS classes, Brandeis’ requirements were fairly lax (See Appendix). For a Bachelor of Arts, the only math class that was required was Discrete Math, and for a BS you just needed to add a few more to that. If someone wanted a rigorous CS education, it was mostly up to them to seek out the hard classes in machine learning, algorithms, systems, or whatever other advanced topics interested them.

Instead, Brandeis really encouraged interdisciplinary thinking in their general requirements. We were required to take a class in every school, in addition to writing classes and other requirements (see Appendix). This encouraged students in the sciences to take interesting humanities classes, and vice versa, and promoted cross-disciplinary thinking. Additionally, Brandeis really encouraged students pursue multiple majors, which is very unusual for universities. Here is a quote from the academic website:

Brandeis students may choose from a variety of majors and minors offered in four broad areas: the creative arts, the humanities, the sciences and the social sciences. A number of these programs are interdisciplinary by design and draw faculty from several different departments. Nearly half of our undergraduates pursue a double major, often in fields on opposite ends of the academic spectrum. Students may pursue up to a triple-major and/or triple-minor.

Since it was so encouraged, and because I was a band geek in high school, I decided to pursue a double major in computer science as well as music. This was a very cool opportunity for me, as I definitely would not have been able to put as much effort into understanding and performing music otherwise. I got to play lute and recorder in an early music ensemble at Brandeis (which was one of the best experiences of my life), and got to take extra classes in music history, theory, and composition. I definitely put more effort into my computer science degree, and would not stand a fighting chance competing against other music majors from other universities, but I really appreciated this rounding out of my education. In a way, the two majors really complimented each other - when I was sick of CS I could work on music, and vice versa. Additionally, I could use my knowledge of music to work on personal projects related to music, or work with professors for cross collaborative work. These projects were always my favorite to work on, and my passion really showed in the end results. For example, here is a 24 hour project from HackMIT where my team made a touchpad that played music, and this is my final project for an electronic composition class where I made a JavaScript improvisation algorithm. Recruiters and technical interviewers also loved when I talked about these projects, as they were unique and my passion for them was evidently higher than someone’s generic project idea.

Brandeis also has a large history with social justice on campus. The school was founded by Jewish people when schools like Harvard had quotas on Jews and other minorities. The school was founded on the idea that anyone could get an education, regardless of any quotas or other stigmas. Especially now, students at Brandeis are very social justice minded, and are quick to speak out about any inequalities they see in the world or on campus. There are many events on campus meant to promote and educate on these issues, leading to students from all different backgrounds having knowledge about various social issues in our society.

Now that I’m graduated from college, and have entered the workforce (dun dun dun), I’m really starting to appreciate having the extra humanities education, which has strengthened my writing abilities and communication skill, and improved my insight on the world at large. I wish I had taken some more classes in college such as machine learning or linear algebra, but I’m happy with the tradeoffs I made. It’s a very different part of the brain that’s exercised in these classes, but that part of the brain is extremely important for the work I do now. I’m also not claiming that I’m some humanities god, with amazing writing and communication skills - I’m far from it actually. I started this blog because I wanted to try to improve my technical communication skills, since I noticed that they were lacking. I’m just sharing what I’ve found to be useful skills for software engineers that are not often talked about. So without further ado, here are my reasons why humanities skills are important for software jobs.

Communicating With Others

Other Engineers

When people think of software engineers, they may think of some lonely hacker sitting in a dark basement somewhere, pumping out code for hours at a speeds of 100 WPM. They may occasionally get a ping from their boss asking them to do something, and then three days later have it done for them: Source.

This may be true for some software jobs, but at least for mine, it could not be farther from the truth. I am constantly talking with other engineers on the team to try to learn how the current codebase works, get ideas on how to build certain features or fix certain bugs, or discussing future plans or optimizations. You will also have to give presentations regarding your work, where you may be explaining to your whole team (or even more broad technical audiences) what your project is, what the technical challenges are, and how you solved them. You want to be able to communicate your ideas clearly in these cases, and this comes with practice. These discussions are happening all the time, and being a good communicator means that you’ll be able to clearly and efficiently work with other developers, by talking through these ideas with them and clearly explaining your thoughts on certain proposals and solutions.

Communicating with other engineers is also a large part of software job interviews. The focus of your interview will be working through whatever problems your interviewer is giving you, but they aren’t only grading you on getting the “right answer.” For the most part, they’re going to be evaluating how you work with the interviewer to come up with an answer. You’re going to need to take what the interviewer says, come up with ideas for solutions, communicate these solutions to your interviewer, listen to their feedback, incorporate that into your solution, and then communicate your solution while coding. This is because companies are not just looking for someone who can get the best answers, they want someone who is easy and pleasant to work on these types of problems with. Even if you have a perfect algorithm for the coding question you were given, if you just write the answer out with no communication, that will not be a good interview. The interviewers are looking for strong engineers who are also able to communicate their ideas well and work with others.

In the end, you don’t want to be a smart software engineer but who is awkward and unable to communicate their ideas. Practicing your oral communication skills and presentation skills will help make you much more effective at your job, make it easier for others to work with you, and be a more convincing interviewee.

Non-Engineers

Communication skills are also important for communicating with non engineers. The amount of this communication will depend on your exact job, but your role may have you talking directly with product managers, UX designers, lawyers, community members, users, or even customers directly. In these cases, you will have to communicate your technical ideas in a way that can be understood by someone who may have never written any code before. They will have questions about how your code works or whether certain features are possible. It will be up to you to explain these things in clear ways, so that there is no ambiguity for the other stakeholders. In the case of working with customers directly, you will have to be able to communicate with them in a way that leaves no ambiguity to the end product, and explain to them what is possible and what is not feasible in the scope of the project. You will also have to set expectations with them, and even convince them that certain features they have in mind will not be necessary.

Having good communication skills will significantly lower the amount of back-and-forth with non-engineers, and will increase the chance of them being pleased with your end result. Communicating technical ideas to non-technical people in a way that leaves them confident in you and not confused with technical jargon is a difficult task, but one that will make you a much more valuable engineer.

Writing

Software engineering is also surprisingly a lot of writing, which is related to communication, but deserving of its own section, since it’s so different from oral communication. The main offender here is design documents. At Google and many other companies, any large feature or plan must come with a comprehensive document that explains what you want to do, why you want to do it, your proposed solutions, and what the pros/cons of those solutions are. This process may take days to weeks to finalize, with engineers from your team debating and discussing all of the ideas. If you write a good design document, you’ll be able to clearly explain the great engineering ideas in your head to everyone else, and you’ll be able to get clear feedback on them without any miscommunication. Additionally, these documents are priceless for the future, when someone wants to go back and see why a certain feature was built. In this case, they will be able to see your design doc, and clearly understand why you did something, and hopefully learn from it so they don’t have to reinvent the wheel. They’re also great for showing off your own technical abilities for promotions (more on that later). A good design document will save many engineering hours, make sure the product of those engineering efforts are the best they can be, and will preserve those ideas for anyone who needs them in the future.

There is also writing for the process of performance ratings and promotions. At Google, every performance cycle, you need to make the case for why your work is demonstrative of your current engineering “level.” Additionally, if you’re trying to get promoted, you have to make an even stronger case for why your work is indicative of the next engineering level. Of course you actually need to do the work to demonstrate these things, but you also have to have the writing and communication ability to explain why your projects are indicative of good work with high impact in a way that’s succinct and convincing. Additionally, having well written design documents will help prove your case for a good performance review, as the technical challenges you’ve overcome will be clearly explained in the document you’ve already written. In this case, your communication skills have a direct effect on your software career and compensation, so it’s important to know how to clearly communicate your contributions to your team.

Besides the larger documents, there are also other short documents and writing snippets that are crucial to software. You may have to write a document on how a certain feature works, describe the results of an experiment, or even write a postmortem document if something you built breaks. In all of these cases, the other engineers you’re communicating to will benefit greatly from clear and concise documentation, so that the messages you’re trying to write about get understood.

Your job may also involve you writing an API or SDK that is accessible to the public. If that’s the case, then your audience isn’t just engineers at your company, but rather engineers all over the world. In that case, you will have to write a lot of technical documentation on how to use the API, what each endpoint does, and include examples to make sure nobody gets confused. I love whenever companies go out of their way to make API documentation accessible and easy to understand, and I cringe whenever an API’s documentation is so bad that I have to look at their source code to see what it’s actually doing. My personal favorite is indico.io, which has super easy documentation to get started on their APIs. Your software may be amazing, but if the documentation is confusing, nobody will use it.

There are also the small points of communication. You have emails to and from teammates, comments in your code, git commit messages, comments in bug reports, comments in code reviews, and comments on other people’s documents. These items may seem small, but they have large effects. All of these are used to communicate ideas to other engineers, so they understand what is going on in the specific context. These small places for communication need to be taken very seriously, and the engineers who can write good comments will make things significantly easier for everyone else, especially after the fact when these comments will be read to get context of the situation at that time. These “artifacts” of your work and technical ability can also be referenced by the performance documents above, to display your work in a positive light.

Reading

In addition to writing, there is also a lot of reading in software engineering. I mean, that’s what you’re doing right now, right? Your software engineering career will have you reading language tutorials, software documentation, books on software engineering, blog posts, design documents, and Stack Overflow comments. Growing and developing the ability to read these types of documentation is extremely important, as well as the ability to reason about and retain the information in them, so you can learn from them and grow as a software engineer. Especially since the world of software engineering is constantly evolving, it’s important to keep up to date with what’s going on out there, and reading is the best way to do that.

Besides reading technical documentation, it’s also useful to read generally about the world around us. There are plenty of books related to software which are not technical documentation, but about the history of some technology or software, or about the personalities behind tech. It’s extremely valuable to have context behind this technical world we’re in, and having an aptitude for reading can come in handy.

Reading also comes in handy for learning how to write and communicate - when you read more, you’ll see more good examples of writing, and you’ll be able to learn how to write just as well. My friend Dan who works at YouTube with me recently said that he started reading books again because: “I haven’t read a book in so long I’ve forgotten how to English.” He was good at writing documents, but reading helped him be able to quickly communicate his ideas to his teammates and other stakeholders in his projects. By reading books of any kind, you’ll help expand your brain and improve your writing and communication skills.

Finally, reading should be fun! If you’re deeply interested in a topic, then it’s a great feeling to be able to take a book to the beach and give yourself an hour to expand your knowledge.

Conclusion on Communication

Hopefully this is not a very controversial point - we’ve all had to either deal with a professor or student who is extremely talented in science, but were awkward and absolutely unable to communicate their ideas to other people. To get information from them, you have to incessantly ask them very directed questions and hope that gets you the information you need, or just give up working with them in general. If not a person, then you’ve definitely seen poorly written software documentation, or even an offhand Stack Overflow comment that’s impossible to understand. In that moment, you probably wish that whoever wrote it took the time to properly communicate their ideas, and had the skills to be able to do so.

At the same time, hopefully you’ve had some good experiences with communicating with engineers: a beautiful API documentation, or a very charismatic speaker at a conference. Good communication makes an engineer more effective, more recognized, and more pleasant to work with. As a software engineer, you should consider these communication skills equally important to your coding and technical skills.

Understanding the Larger Scope of Your Work

Case Study: IBM and the Holocaust

CONTENT WARNING: There is some discussion of the Holocaust in this section, including graphic quotes. The source for all of this information and all the quotes are from the wonderful book IBM and The Holocaust. If you cannot stomach holocaust discussions, please skip to the next section.

As engineers, we’re often bogged down by technical details of our work. We’re asked to create efficient algorithms that can be managed over a certain QPS with low latency, and few network connections. These are all important technical questions, but there are other important questions when building software which raise questions beyond the technical scope. For example, is the work you’re doing ethical?

One of the most egregious example of “software” being used for wrong is the use of IBM Hollerith tabulating machines in Nazi Germany during the Holocaust. I use software in quotes because it’s not technically software, but it’s basically the same idea, hardware programmed to do a specific task. For those who don’t know, in the 1940s, Germany was politically overtaken by the Nazi party, lead by Adolf Hitler, which had a very clear objective in creating a master race of Germans by weeding out Jews, Roma people, disabled people, gays, and many other groups. The Nazis very specifically targeted the Jewish population, blaming them for the economic depression, and claimed that the Jews wanted to enslave all Germans. This talk eventually turned into blacklisting these groups from society, and sending them to concentration camps which eventually turned into mass extermination camps. According to Wikipedia, the death toll of these camps was “Around 6 million Jews; using broadest definition, 17 million victims overall.” This amounted to about two thirds of all European Jews. This tragedy is extremely well known, but what is not well known is how these machines played a part in orchestrating this genocide.

Let’s start with some history. In 1890, Herman Hollerith patented the tabulating machine, inspired by the inefficiency of the US census. Each card would have some data about some entity, and the machines could sort and summarize this data based on arbitrary columns. If you know CS, you know the power of sorting algorithms like merge sort which runs in n*log(n) time, and you can imagine the benefits this machine would have in optimizations and quick turnarounds. This technology was amazing to the US Census, and saved them significant time and money in terms of being able to categorize their population (See Appendix: Quotes 1).

This technology was extremely profitable, and several governments paid to lease this technology, making specific punch cards and tabulating machines for each use case.

Example sorting machine:

Eventually, the technology went into the hands of IBM, which was at the time run by Thomas J. Watson. Watson was an incredibly effective salesman, and was motivated by selling as much as possible. He was ruthless in business, and had almost a cult like personality surrounding himself at IBM. This drive for success is what lead him to deal with any client, no matter how morally abhorrent. This client of course is Nazi Germany. To quote IBM and The Holocaust on IBM’s involvement:

[Watson’s] company, IBM – one of the biggest in the world – custom-designed and leased the Hollerith card sorting system to the Third Reich for use at Bergen-Belsen and most of the other concentration camps. International Business Machines also serviced its machines almost monthly, and trained Nazi personnel to use the intricate systems. Duplicate copies of code books were kept in IBM’s offices in case field books were lost. What’s more, his company was the exclusive source for up to 1.5 billion punch cards the Reich required each year to run its machines.

You cannot say that Watson and the engineers who worked for IBM did not know about the abhorrent use case of these punch cards. For one, Adolf Hitler’s intentions were extremely well laid out.

When Hitler came to power, in January 1933, he made an open promise to create a Master Race, dominate Europe, and decimate European Jewry. Numberless racial laws – local and national – appeared throughout the country.

In the coming months, Nazi Germany banned Jewish businesses from advertising, Jewish people were captured and tortured in the streets, and concentration camps for political prisoners and Jews would be established. This was not unknown to the world, as there were over 100,000 protestors in New York spreading this news, and frequent New York Times stories. There was even a boycott of companies that did business with Germany, but IBM was not targeted, as the power of the punch card machines was not obvious, and IBM did business in Germany through a holding company. But Watson was extremely involved in the design and execution of punch cards running Nazi Germany, as he basically saw dollar signs ready to be made. See Appendix 2: Quotes on Watson’s Lack of Ethics.

Previous to the punch cards, the Nazis could not systematically attack Jews and other races considered non pure. They could of course target and harass select people, but they were not able to really find the previously Jewish families who have since converted and assimilated, as many did. However, these punch cards gave the Nazis the power of computation, and allowed the Nazis to systematically target specific populations, and be very specific about their needs. For example, they were extremely concerned with bloodlines, and as such targeted anyone who had any Jewish in their blood, even if they were practicing Christians. Once punched, the cards could generate lists of anyone with Jewish grandparents. In a modern database, you can imagine that as a horrifying SQL query. See quotes 3.

Using his Nazi connections, Watson was able to secure the Nazi census as a contract, and began working on the whole thing. The Nazis had 500,000 census takers through the country, taking the names and other information of all its citizens under coercion and deceit. They then employed data punchers, who could take this data and transfer it to the coded punch cards which could be sorted based on the Nazi race scientist’s whims. Mixed with medical data, they could find Jews, gypsies, disabled people, people with disease in the family, any people with any other characteristics that were not in line with the “master race.” These people would be targeted for mass sterilization, loss of citizenship and the right to work, theft of property, and of course mass genocide. See quotes 4.

And Watson was well aware of what the technology was being used for. He regularly visited Germany, and even won an Order of the German Eagle award. He was keyed in on key Nazi speeches and ceremonies, and frequently gave his regards to the Nazi party, though he was smart enough to not keep that much of it in writing.

IBM was guided by one precept: know your customer, anticipate their needs. Watson stayed close to his customer with frequent visits to Germany and continuous daily micro-managed oversight of the business.

Watson didn’t need to read about Aryanization in newspapers. He discovered it personally. In July 1935, Watson visited Berlin. That July, Nazi thugs ran wild in the streets of Berlin smashing the windows of fashionable Jewish stores. One of those department stores was owned by the Wertheims, family friends of the Watsons. The Watson family learned that to protect the store, Mr. Wertheim first transferred the property to his Aryan wife, but then ultimately decided to sell ‘for next to nothing’ and escape to Sweden. On another visit to Berlin, the Watsons and other IBM executives were invited to an elegant reception at the Japanese embassy. While sipping tea in the garden, a German diplomat boasted that the exquisite home formerly belonged to a Jew who fled the country. Such new ownership of greatly discounted homes was now common in Berlin.

So it’s clear to say that:

1) IBM developed punch card technology specific to Nazi interests and purposes. 2) This technology specifically aided the Nazis in killing a significant population based on hateful ideas. 3) IBM engineers and Watson profited off this genocide. 4) IBM engineers and Watson were fully aware of the consequences of their actions. 5) If IBM had not taken contracts for Nazi Germany, the Nazis would not have been able to so effectively target vulnerable populations.

I won’t summarize the whole book on the Nazi involvement (I haven’t finished it yet), nor is that the point of this blog post. These punch cards would go on to be used for many aspects of horrifying Nazi accounting. But as a final point, what strikes me the most about this detailing is the strict engineering requirements of this project. As a software engineer, we’re often asked to go back and forth to define specifications for our software. It’s extremely jarring to see this same behavior applied to such morally awful software. See the quotes in the appendix, but to give one particular callout quote:

Every day, transports of slave laborers were received. Prisoners were identified by descriptive Hollerith cards, each with columns and punched holes detailing nationality, date of birth, marital status, number of children, reason for incarceration, physical characteristics, and work skills. Sixteen coded categories of prisoners were listed in columns 3 and 4, depending upon the hole position: hole 3 signified homosexual, hole 9 for anti-social, hole 12 for Gypsy. Hole 8 designated a Jew. Printouts based on the cards listed the prisoners by personal code number as well. Column 34 was labeled ‘Reason for Departure.’ Code 2 simply meant transferred to another camp for continuing labor. Natural death was coded 3.

It’s wild to imagine the amount of thought and back-and-forth that was probably required over deciding which punch holes would designate which information.

Finally, if you’ve ever seen the tattoos that were marked on concentration camp victims, you may be interested (or horrified) to know that these IDs were the IBM punch card numbers that identified that specific person. See wiki article

What to make of this all

Sorry for the heavy handed section before, but I felt like it was important to lay it all out in the clear. In this specific case, I would hope that if you were an engineer working at IBM at this time, you would have the moral inclination to not work on this project, or join a new company altogether. You may even decide to leak details to the press, to try to get the public opinion If you were an executive at the time, I’d hope that you would use your leverage to try to convince the company to not take these contracts, maybe even quitting in protest to send a message to the company.

It’s extremely important to know the story of IBM and the Holocaust, as it is a clear indicator of when software went too far and caused too much damage. But of course, things are not so simple now. For one, computers and programming ability are much more common now, and it is much easier to create software, for good or for bad. There are also of course a lot of more nuanced situations that aren’t as clear cut as the one mentioned above. But just in the last few years, there have been several instances of engineers standing up to morally dubious projects.

For example, when US President Donald Trump signaled (read: dogwhistled) that he would be in favor of a database tracking Muslims in the US, the website www.neveragain.tech was published, with a list of engineers who pledged to never build such a database again, even citing previous history such as IBM’s involvement in the holocaust. A lot of people might say “anyone could do this, so I might as well” when given a task, but this kind of large scale protest sends a message to companies that might have previously considered taking on projects like this, telling them that they will lose talent if they do so.

Similarly, a project within Google, nicknamed “Project Maven” was originally a US Department of Defense contract dealing with machine learning in military weaponry. Once details leaked, there was an immediate backlash with engineers across the organization, and the pressure got Google executives to cancel the project. There are companies such as Palantir who already heavily work with government agencies like the NSA which are wildly unpopular, and help the government spy on Americans: 1, 2. As a result, many engineers boycott these companies, and send the message to other companies not to follow in their tracks.

My point with all this is that a humanities education encourages you to think about these larger ethical and historical issues. There will always be people looking to profit in unethical ways, but by having the historical context behind previous unethical uses of software, and the ability to reason about how certain projects may be used in an evil or unethical way. And if these unethical uses are discovered, engineers have the bargaining power to do something about it, and seriously make the world a better place.

Thought in Software Design

The above ideas were mostly about large scale ethics, but even inside of innocent software projects, there are a lot of “larger” ideas to think about in terms of software. For example, if your software collects user information including race and religion, how will you design your software to make sure this information cannot be abused? How will you design your software so that if someone after you decides to use it for evil, they will not be able to? How will you design your software so that if someone hacked into your database they would not be able to abuse this information? When making software you should not only be focused on the tech side, but on the human side in terms of what your abuse vectors are. A recent example of this is the GDPR regulations that recently were rolled out in Europe, which were designed to ensure that users of software have adequate control over the data the software collects on them. Another example is HIPAA, which is a US Act that regulates data involved in electronic health care. These laws are great, but as software engineers, we should not wait until laws are created to act ethically - we should incorporate these ideas into our software one day one.

Another important point of reasoning comes in with algorithmic bias. It may be very weird to think about algorithms as biased, but algorithms are written by humans and subject to the same biases that humans are subject to. This bias is much more rampant with the advent and popularization of machine learning, where the decision criteria is not defined by the engineers. Instead, engineers provide test data with labels, and the machine learning algorithm tries to predict what part of the test data results in the desired labels, so it can label new unlabeled data itself. For a great introduction to the topic, see the CPG Grey video How Machines Learn. However, if there is bias in the input data, there will surely be bias in the machine learning algorithm. For example, it was recently released that an Amazon internal project to try to predict success of candidates based on their resumes was canceled after it was found that the algorithm highly penalized women just for being women, not for anything involving their skills or experience. This most likely came from a bias in input data which was mostly men, and an already existing cognitive bias that was causing Amazon to disproportionately hire men. It’s worth noting that this project was never used, and it was good that Amazon caught this bias, but it should be a subject on your mind as well.

When designing algorithms that have impact on people and their lives, we should be extra careful to make sure it does not have any bias, especially towards already disadvantaged groups of people. If you’re designing a resume reader that will affect people’s chances at being hired, make sure it is not disproportionately rejecting women or people of color. If you’re designing a system for showing comments or posts, make sure that you’re not inadvertently promoting hateful and divisive content, even if it’s great for user engagement. And so on and so forth.

There’s a lot I can say on the topic, but in the end, it’s good to have a background of all the ways that your algorithms and software will be used for good, and not evil. I’m reminded of Cassidy Williams who used to work at Venmo, who posted recently about implementing a block feature in Venmo, since stalkers used Venmo requests to harass people with messages when blocked on all other platforms. No other engineers before her thought to make a block feature, since they didn’t think about this specific case. It’s important to think about these “human” features of tech; how your service could work against your original ideas, or how people could abuse your service. This type of thinking also helps when your team is diverse and comes from diverse experiences, but as an individual it’s good to read about where other software is failing, and how you can improve your own software. There are plenty of people who post blogs, tweets, YouTube videos, and other media about these issues they face regularly, and so it’s good to look out for them.

The other way to think of this problem is to think of software that will increase the net good in the world. There are many problems in this world currently, and if you can pinpoint one of these issues and think of a genuine way to solve it with software, your code will be increasing the net good in the world! If you don’t have any ideas, there are plenty of non-profits that are in dire need of software engineers, and so volunteering a few hours for them can make great strides towards helping people.

Being a Well Rounded Person

Finally, I believe that a humanities education should be pursued just because it makes people more well rounded. This of course plays into the other benefits of communicating better and understanding the world better, but it’s also just good to learn about the humanities for the sake of learning about them. We as people are an extremely interesting species, and there is so much to learn about us that its overwhelming. It’s not good for people to learn about more than just science and technology, to have a more nuanced background and understanding of the world. Your further studies into the humanities could even spark an interest in literature, music, politics, history, or any of the many other humanities fields. Learning about these things is a great way to become more well rounded, have conversations with others about complex topics, and not just be someone who knows only about STEM related topics.

You can even use your new experience learned from these studies, and leverage your software engineering skills to make unique projects related to the intersection of the two fields. These types of projects tend to be the most unique and interesting to people, even if they’re just used for your own practice or to boast about on a resume. Learning these skills can also make you more sympathetic to the users of your software, as you’ll be able to understand the perspectives of people who do not dedicate their lives to technology.

Finally, learning about the humanities is a great way to expand your mind, and exercise the parts of it that you do not normally use. This in turn can help make you a better engineer, as a lot of being an engineer is thinking through problems and thinking about diverse situations. I’m not a neuroscientist nor do I have conclusive data on this, so I’m not making any promises in this. However, from personal data, most of the best engineers I know have many interests in topics outside computer science. For example my friend Ryan Marcus who is almost done with his PhD in CS from Brandeis graduated with a degree in gender studies as well as computer science in his undergrad. I don’t want to make broad statements based on one person, but I just wanted to show you that you can pursue a humanities education without compromising your computer science abilities, and in some cases it may help expand your brain in the right way.

In the end, learning about the humanities is great for your software abilities, but these subjects also great to learn for the sake of learning about us as humans. By being a well rounded person, you’ll learn more about the world, and can think about your software as it fits into this larger world of ours.

What To Do Now

So now you’re gone through this post, and are hopefully convinced that a humanities education is important for engineers, both for your own benefit as well as the benefit of the users of your software. But what should you do now?

If You’re Still In School

If you’re still in school, take my advice to heart and take a humanities class that interests you, and that that you think will improve your communication skills. Essays may be hard and confusing when you’re not used to them and when you’re the only engineer in a class of humanities majors, but the difficulty will be good for you. If it’s a subject you’re interested in, such as a specific period of history, or a specific topic in politics. It would be good to take a class that helps understand the struggles of minorities and other disadvantaged people in the world, so you can learn further about their struggles and how you can use that information to improve your software engineering. You don’t to pick up an entire new major or minor, but taking a few classes outside your realm of expertise will go a long way.

Additionally, when designing a new project, try to write up a design document to go with that, and add that documentation to your Github. This will help you learn how to discuss technical ideas in English, and will also be a great way to show your project off. You can also create a blog like mine, or volunteer to give presentations at your school about various technical topics to help others with computer science.

If You’re Out Of School

If you’re out of school, that does not mean that you still can’t learn on your own! Watch some videos on YouTube on some topics that interest you. History is a great place to start, but there are lectures on literally anything online nowadays. Find a subject you’re interested in, and do a deep dive into it.

Also, get a kindle! A Kindle costs about $100, and basically lets you store as many books on it as you’d like. The Kindle has literally changed my reading life, and I went from reading ~0 books a year to reading several this year. Ebooks are generally fairly cheap, but there are a ton of public domain books as well. If you’re interested in any recommendations, check out my Goodreads account. Besides books, find some bloggers and read their posts. Follow them on Twitter as well!

Finally, try to find ways to communicate about ideas in tech. Like above, you can write documentation for your own personal projects, or you can even go my route and create a blog to write about topics like these. Not only will it help you, but you’ll also help everyone who learns from your blog!

If you’re a Teacher of CS

If you’re a teacher of computer science, at the high school or college level, I urge you to please incorporate humanities and ethics into your lessons. As someone who loves teaching computer science to people, it terrifies me that I might one day empower someone to create software that is used for harm instead of good. There are many ways to incorporate humanities into your basic computer science lessons. For example, if you’re learning about for loops, you can loop over a corpus of some Shakespeare play to search for words. Another example is defining algorithms by using knitting as an example, as knitters basically follow algorithms to create their works. There are plenty of ways to incorporate ideas of the humanities into your lessons at all levels, and even at the base level they promote the idea that the humanities and computer science should work together, not be enemies. A good example of using humanities in a computer science class is Wheaton College’s Computing for Poets, a CS class meant for English majors. Check it out for any material you can add to your own curriculum.

Additionally, you can bring more of the humanities elements into your classrooms. Have debates about certain issues in tech, or about what the best way to implement something is (even if there is no right answer). Require students to make presentations on their technical solutions to a problem, on an issue that faces tech currently, or on a new technology or programming framework. Make them whiteboard solutions to problems in class, and teach them how to work through problems orally with others, mimicking a software interview. You can also make them create README.txt files for their submissions, and grade them on how well they explain their ideas in addition to how well they coded it up. Encouraging these types of thinking is tough, but will really prepare students for the realities of the field.

Please also bring ethics into your classroom, and bring up some hard hitting questions and debates about what is and isn’t ok to do. My Cryptography professor did just this on our first day: mentioning that what we learned in the class could be used for good or evil, and to please use it for good. Especially for high school teachers, you can afford a few days in the year to talk about current ethical issues in computing, or about past ones such as IBM and the Holocaust. Your students will come out as much better people and engineers for it, and you can feel good about teaching them the ethical foundations to make the right decisions once they’re out of your class.

If you’re in charge of a CS program, you should encourage your staff to bring humanities and ethics into their lessons. Give them the resources and space to create these lessons, and do it in a way that does not make them feel like they’re compromising the rest of their lessons. If you do it right, your program and the quality of its graduates will see a significant improvement in this capacity.

If You’re a Humanities Minded Person

Finally, if you’re a humanities minded person who is interested in tech, I hope this post encouraged you by showing that that this type of thinking is not only compatible with tech and software engineering, but actually encouraged and actively useful. A lot of humanities minded people think tech is not for them, and they would rather do something else. I want to encourage you to keep it up, and use your unique skills to be a great software engineer! The field is in dire need of people like you, as more diverse teams and companies make better products, period.

Conclusion

Hey everyone! This post is a little bit of a deviation from what I normally talk about on this blog, but I hope you enjoyed it nonetheless. Hopefully, I’ve convinced you that it’s important to have a healthy mix of humanities into your computer science degree to improve your communication skills, help you be informed about the possible larger implications of your software projects, and to help you be a more well rounded person.

As always, I’ll really appreciate your comments, either in emails or in whatever discussion forums you post this to (I’ve deleted the Disqus comments, since tjhey have clickbait ads). Especially since I don’t have much experience writing about these kinds of things, I’d love to know what you think. If people really like this, I can write more about topics in ethics and humanities as they relate to CS. And as always, please share with friends and coworkers as well, and help get the word out. You can always retweet me as well, or just tag me. Also you can join my mailing list to get an email when I post something new.

Thank you all so much for your support!

Appendix

Brandeis University Requirements

General Requirements

Source

First Year Writing Seminar (UWS)

Two writing intensive courses (One may be substituted with an oral communications course)

Quantitative Reasoning

Third semester of foreign language

Non Western/Comparative Studies

One course in each of the following groups: Creative Arts Humanities Science Social Science.

Completion of at least one major.

Note: Classes can double count for these categories. You can also transfer credits from AP Classes

Computer Science (BA) Requirements

Source

Introduction to Programming in Java (or AP CSA)

Object Oriented Programming

Data Structures & Algorithms

Discrete Mathematics

Operating Systems

Four CS Electives

Additional Requirements for BS in Computer Science

1st semester calculus (Or AP Calculus A)

Introduction to Statistics (Or AP Statistics)

Theory of Computation

Structure & Interpretation of Computer Programs (SICP, Scheme)

One Extra Elective

Quotes from IBM and the Holocaust

All quotes are from the book IBM and the Holocaust, which you should read.

1: Saving the US Census Money

[Hollerith’s] statistical feat caught the attention of the general scientific world and even the popular newspapers. His systems saved the Census Bureau some $5 million, or about a third of its budget. Computations were completed with unprecedented speed and added a dramatic new dimension to the entire nature of census taking. Now an army of census takers could posit 235 questions, including queries about the languages spoken in the household, the number of children living at home and elsewhere, the level of each family member’s schooling, country of origin, and scores of other traits. Suddenly, the government could profile its own population.

2: On Watson’s Lack of Ethics

Watson was no Fascist. He was a pure capitalist. But the horseshoe of political economics finds little distance between extremities. Accretion of wealth by and for the state under a strong autocratic leader fortified by jingoism and hero worship was appealing to Watson. After all, his followers wore uniforms, sang songs, and were expected to display unquestioned loyalty to the company he led.

Nazi Germany offered Watson the opportunity to cater to government control, supervision, surveillance, and regimentation on a plane never before known in human history. The fact that Hitler planned to extend his Reich to other nations only magnified the prospective profits. In business terms, that was account growth. The technology was almost exclusively IBM’s to purvey because the firm controlled about 90 percent of the world market in punch cards and sorters. As for the moral dilemma, it simply did not exist for IBM. Supplying the Nazis with the technology they needed was not even debated.

3: On the usefulness of the technology for the Nazis

At the vanguard of Hitler’s intellectual shock troops were the statisticians. Naturally, statistical offices and census departments were Dehomag’s number one clients. In their journals, Nazi statistical experts boasted of what they expected their evolving science to deliver. All of their high expectations depended on the continuing innovation of IBM punch cards and tabulator technology. Only Dehomag could design and execute systems to identify, sort, and quantify the population to separate Jews from Aryans.

In the absence of an explicit law defining exactly who in Germany was a Jew, Nazi persecution was far from hermetic. For years, such a definition would have been a cloudy exercise. Even if Nazis could agree on such an exegesis, no one could back up the definition with hard data. Since the advent of the Third Reich, thousands of Jews nervously assumed they could hide from the Aryan clause.

But Jews could not hide from millions of punch cards thudding through Hollerith machines, comparing names across generations, address changes across regions, family trees and personal data across unending registries. It did not matter that the required forms or questionnaires were filled in by leaking pens and barely sharpened pencils, only that they were later tabulated and sorted by IBM’s precision technology.

4: On the effect on jews and other population

Ironically, while all understood the evil anti-Jewish process underway, virtually none comprehended the technology that was making it possible, The mechanics were less than a mystery, they were transparent.

Throughout 1935, race specialists, bolstered by population computations and endless tabular printouts, proffered their favorite definitions of Jewishness. Some theorems were so sweeping as to include even the faintest Jewish ancestry. But most tried to create pseudo-scientific castes limited in scope. These latter efforts would encompass not only full Jews who professed the religion or possessed four Jewish grandparents, but also the so-called three-quarter, half, and one-quarter Jews of lesser Jewish lineage.

Hitler wanted the Jews identified en masse. Once drafted, the Nuremberg regulations would be completely dependent upon Hollerith technology for the fast, wholesale tracing of Jewish family trees that the Reich demanded. Hollerith systems offered the Reich the speed and scope that only an automated system could to identify not only half and quarter Jews, but even eighth and sixteenth Jews.

In the sterilization program’s first year, 1934, more than 84,600 cases brought to the Genetic Health Courts resulted in 62,400 forced sterilizations. In 1935, 88,100 genetic trials yielded 71,700 forced sterilizations. Eventually, sterilization was viewed as merely preliminary to more drastic measures for cleansing the Reich. Zahn warned in a statistical journal article: ‘population politics, according to the principles of racial hygiene, must promote valuable genetic stock, prevent the fertility of inferior life, and be aware of genetic degeneration. In other words, this means superior life selection on the one hand, and the eradication of genetically unwanted stock on the other hand. The ethnic biological diagnosis is indispensable to carry out this task.’

5: On the Engineering effort required

‘Be Aware!’ reminded huge block-lettered signs facing each cluster of data entry clerks. Instructions were made clear and simple. Column 22 RELIGION was to be punched at hole 1 for Protestant, hole 2 for Catholic, or hole 3 for Jew. Columns 23 and 24 NATIONALITY were to be coded in row 10 for Polish speakers.

Now a lightning storm of anti-Jewish legislation and decrees restricting Jews from all phases of academic, professional, governmental, and commercial life would be empowered by the ability to target the Jews by individual name. Moreover, by cross-sorting the Jews revealed in Column 22 row 3 with Polish speakers identified in Columns 26 and 27 row 10, the Reich was able to identify who among the Jews would be its first targets for confiscation, arrest, imprisonment, and ultimately expulsion.

Then came the awesome sorting and resorting process for twenty-five categories of information cross-indexed and filtered through as many as thirty-five separate operations – by profession, by residence, by national origin, and a myriad of other traits. It was all to be correlated with information from land registers, community lists, and church authorities to create a fantastic new database. What emerged was a profession-by-profession, city-bycity, and indeed a block-by-block revelation of the Jewish presence.

Execution was coded 4. Suicide coded 5. The ominous code 6 designated ‘special handling,’ the term commonly understood as extermination, either in a gas chamber, by hanging, or by gunshot.

Antisocial was to be coded 1 in one column. In a second column, diseases such as blindness were coded 1. Mental disease was 2. Cripples were 3. Deaf people were 5. Parents who had already been sterilized were to be noted with an ‘s’; children already sterilized ‘because of a parent’s sickness’ were noted ‘as’. Uniform codes were established for occupations. Factory workers were coded 19, hotel and guesthouse workers were 23, theatre artisans were 26. Unemployed persons received the code number 28. These codes were handwritten into field 8 on the forms. Diseases were also coded: influenza was 3, lupus was 7, syphilis was 9, diabetes was 15; they were entered into field 9.