What technology can learn from the humanities.

Much has been written about what non-engineers in tech firms can learn from computer science. Learn to program and script, understand basic architecture, learn to speak the engineers’ language (because, lets face it, there is one). But in all the clamor for technology companies to learn more tech, hire engineers in test instead of test analysts, have designers who also program and project managers with computer science majors, let us take a moment to consider what computer science could learn from the humanities.

In my first job, there was a push to hire people without engineering degrees. Why? Because they solved problems differently than engineers did, and thus, they looked at problems a little differently. For a QA – this led them to different bugs than other people would find. However, I have seen this same phenomenon in my other companies as well. So what does the study of humanities really have to offer a modern technological firm?  The answer is in the approach to thinking, collaborating, and to life.

To paraphrase what Alan Cooper so eloquently put- engineers feel at home in the state of problem solving and tinkering that breeds instant frustration in most people. In firms that are too one sided (toward the engineering side) cool new technology, endless iterations to pare down the code, and endless API options can obscure what they are really trying to do- make something easier. But user experience isn’t the only thing to learn from humanities.

Collaborative approach. Pair programming is gaining in popularity, and it is a great start. But the humanities has encouraged discussions, team work and communication from the beginning. English majors know how to smooth out the gaps in a paper to make it seem like it was written by one person. How many design specs were clearly written by more than one person? That contradict themselves or don’t take other sections into account?

Holistic problem solving. Engineering encourages you to get down in the weeds, and focus on minute problems. Humanities teaches you to step back, gleen the whole landscape and see the issue in perspective. That mindset may not clear a compiling error, but it may solve an error about the way the features are configured or what features are needed at all, or why they work together they do.

The humanities teach you to challenge the question when you face a problem. Are you asking the right question or solving the right problem? Are you too down in the weeds to see the big picture? Is there a different way to do this? Do you really need to do this? Sometimes just that conversation can pull people up to a different plane of thought and an answer appears.

Beauty. Thats right, beauty. Artists of course, think about the aesthetics of their designs and artwork but the humanities as a whole put a great value in the beauty of what they create. From a well written scholarly paper to the clear tone of high C in an aria, students of the humanities will keep working and reworking not just until something is accurate, but until it is beautiful. In a world of computers that is starting to wake up to the need for interaction design and UX testing, it would behoove engineers to take note from the emphasis the humanities put on beauty.

A team too heavily weighted toward one side or the other is weaker than one with a good balance. While the non-engineers in the company are reading basic programming books or cramming on technical terms and concepts in order to communicate more effectively, the engineers should consider looking to the humanities to help round out their team and their skills. Because really, learning to speak in a common language is one of the core drives not only of business (and technical business especially) but also of the humanities.

Print Friendly
This entry was posted in Mindset, roles, Teamwork. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>