So why does a humanist leave the university and start learning to read and write software?
Good question. I think I can best address it as a system of related questions.  This post offers an initial answer to one part of that system: why, out of all the possible choices, am I choosing to learn the art of programming? The short, “tl;dr” answer is that this particular humanist is intellectually excited by the craftsmanship and challenge of software development, and blessed with the support of friends and access to resources to help turn that intellectual excitement into a practical career reality.
I imagine that most–if not all–doctoral students and their professors have seriously considered leaving academe at one point or another. Once a person reaches this point, zie usually has increasingly clear ideas about why zie would leave, but faces further questions about how zie would do that, and what zie would do next. In my opinion, a reasoned consideration of why a person might stay or move on depends on a relative calculation of personal goals and priorities, an operation which is necessarily idiosyncratic and resistant to generalization. I want to focus instead on the questions of how I am making a transition and what I am choosing to learn next. I hope that the posts and pages of this blog, when considered as a whole, will grow to become a reasonable answer to the how of a career change from academe, at least as it applies to one person. At the outset, however, it seems appropriate to offer some initial thoughts on why I’ve chosen to learn the art of software in particular.
I’m attracted to reading and writing software by some of the same intellectual qualities that I’ve enjoyed in my work as a humanist: the craftsmanship of constructing and communicating arguments, a disciplined creativity in reasoning, and a fascination with the use and logic of languages. In my conversations with working software engineers and my own reflections on the learning process so far, I keep coming back to the craftsmanship and the creative work that unites writers and researchers in the humanities and social sciences with software engineers and architects. At a certain level of intellectual abstraction, writing software well is not so different from writing articles, books, or conference papers well. To speak of the field I know best, I believe that in writing a good historical argument, a historian exercises a disciplined imagination and practical creativity in the use of zir materials and tools, critically deploys the work of, and collaborates with, peers, mentors, and predecessors around the world, carefully attends to nuance and contingent logic in the design and structure of zir assertions, and mobilizes language with elegance and clarity to communicate both the process and the results of the argument. If you consider a program as another form of written argument, I think there are meaningful resonances here. Granted, the parallel is not perfect, and the description is both incomplete and idealized when applied to either endeavor, yet, at least in my experience thus far, there is an underlying intellectual kinship in the art of reasoning and writing as a humanist and as a programmer.
This kinship points to another major attraction for me: the challenge of writing software well. I want to do work that challenges me to think creatively and trains me to think more effectively. Amidst a flood of exhortations to “learn to code [in n easy steps for fun and (quick) profit],” I choose to learn to write programs not because it is easy, but because it is hard. I know that while becoming functionally literate in a language (more or less what “learn to code” usually means) is a valuable foundational skill, it is neither an end in itself, nor at all equivalent to becoming a skilled professional writer. Reasoning well and writing well are not easy in any language. They take an enormous amount of accumulated practice and ongoing effort. For me, the effort is worth it because I think the practice is training me to be a better analyst and problem-solver in general by unlocking new tools and modes of thinking, particularly those drawn from discrete mathematics.
Finally, I am learning to write software because I have the human support and access to physical resources to do so, and I happen to live in a place (the S.F. Bay Area) with relatively abundant opportunities to start. Not everyone has these advantages. I work very hard but I am also very blessed. I would not be learning the art and practice of programming without the support of a considerable human network, and the process is further facilitated by various forms of privilege (i.e. unearned social advantages) from which I benefit in ways I may not even realize. Although my learning process so far could be characterized as one of independent learning and self-study, it would not be possible without the support and encouragement of family, friends, and mentors, including many authors of helpful books, blogs, and tutorials whom I have never met. I want to recognize this support–since it is so often overlooked in favor of a cultural ideal of individual achievement–and begin to express my gratitude for it.
To start, I want to thank my friend, Kyle Kingsbury (a.k.a. Aphyr). Kyle first gave me the confidence to imagine myself programming and started providing me with the tools to do it. Although I did not have any prior training in programming, Kyle had the open-mindedness to connect my experience learning languages for my previous job to the prospect of learning programming languages, and the kindness to use an afternoon off to literally take out a dry erase board and start teaching me the rudiments of programming in Lisp. By hand. That was the beginning. Since then, he has been a great mentor to me in the world of distributed systems and programming more generally. For the record, Kyle is also a wonderful friend and a good person in the broadest possible sense, whose friendship over the last six years has meant more to me than I could possibly express here. Suffice it to say that he has helped me become a better person and a better thinker, and continues to do so.
So, with the help of a network of friends and mentors, I’m learning the art of building software. I hope that in it, I will continue to discover a sense of intellectual excitement and new problems to challenge me. I’ll be writing more about the process here as it progresses.
- I know! Of course I’d take a question like that and break it down into some set of constituent parts. The habitus is too strong! So strong that I made a footnote in a medium without footnotes and then internally, instinctively connected the impulse to do so to a concept from sociological theory… I left this here for you, dear reader, to let you know that I know, that sometimes I’m in on the joke too, and that, at the end of the day, I’m both laughing with you and not sorry. Also, in all seriousness, this site has a pretty decent short explanation of Bourdieu’s use of the concept of habitus .
- Known in some circles as a “thesis.”
- “Zie” (usually pronounced “zee”) is a gender-neutral, third-person singular pronoun replacing the various cases of “he” and “she” in situations where specifying these genders would be inappropriate. I am using this pronoun here to refer to any one person. I think this is a good alternative to using the third-person “they” for singular subjects or the very clunky and gender-binary-reinforcing “he or she.” Since I am referring to any individual person, and all people do not fit into this binary– gender is more complex than this–, I believe this is an adaptation well worth making. There are several systems of gender-neutral pronouns in use today. I am using the zie/zir variant (subj.: zie; obj.: zim; poss. adj.: zir; poss. pronoun: zirs; reflexive: zimself), but, in my opinion, the important point here is the concept rather than the specific system used.
- Yes, I’ve appropriated President Kennedy’s “Moon Speech” to describe the challenge. The original quote from Kennedy is: “We choose to go to the moon. We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too.” NASA publishes the full text of the speech here.
- At minimum, I think we’d need to consider my sex, sexual orientation, race, class, and able-bodiedness and keep adding from there. First steps to overcoming the injustices of privilege include recognizing it for what it is, talking about it, and helping to educate others. One of the most essential things a person can do from a position of privilege is to learn to listen. Really listen. This Prezi by Cassandra Duplacy might serve as a good introduction to the concept of privilege and the problem. I think this blog post by Matt Sweet offers a few good reminders and suggestions for confronting privilege. I also recommend this post by Jamie Utt on listening.
2 thoughts on “Why software?”
I was studying Ruby in Codecademy and found myself referring to their Q&A Forums with a puzzler. Fortunately, someone had already asked my question before and it was answered most eloquently by someone named “augescens”. 15 minutes later, I found myself again in the Q&A Forums and once again, augescens had shared the answer! I just had to find him and thank him.
So I bounced from your Codecademy profile to Twitter to here. I wouldn’t have guessed that you only recently started to learn programming. Thank you sir, your very well-constructed answers are much appreciated!
I’m glad those posts were helpful to you!
Comments are closed.