The Code Less Travelled

“Why on earth do you want to become a programmer?”

Very few people seem to understand my most recent career choice.

I’ve long since lost count of the number of times I’ve been confronted by the question above over the past few years. As a student of English literature, the idea that I might want to explore my options in the seemingly impenetrably techie universe of software development is completely alien to most people. “You do know that computer languages aren’t the same as real languages”, friends scoff derisively, bewildered by the suggestion and frankly faintly amused by the whole idea.

The switch from English to computer programming is a concept that for most people, ironically, just does not compute.

Traditionally, British educational assumptions place most children firmly on one side of the arts vs science divide from an early age. Barring any drastic late development of interest, very few seem to break out from their respective moulds. There are certain expectations placed on young people in Britain from the moment they show particular aptitude for either side of the debate that seem to map out their entire career paths before they’ve even sat their first school exam. Sitting astride that dividing line can be unsettling for students, parents and teachers alike and is often strongly warned against. With the job market continuing to struggle and university places in high demand, failing to specialise by the age of 16 is seen, in some circles, as already preparing to fail later in life.

Yet here I am, a mixed bag of A Levels in English, History, Maths and Further Maths, an undergraduate degree in English Literature and three years of interesting but fairly disparate and somewhat directionless work experience from a period of post-uni meandering. And now firmly in training to be a consultant software developer in test. Unsurprisingly, more than a few eyebrows have been raised.

“What are you going to do with an English degree? Write a book? Become a journalist? Teach?”

Again, the number of times I have had to listen to this sort of reductive reasoning defies belief. Over and over again it has been tacitly reiterated to me through this unproductive line of questioning how baffling and unnatural my shift in focus is to most people. The supposedly limited career options available to me as a result of my ‘pointless’ degree subject are clearly laid out and it would appear everyone knows what sort of employment I ought to be pursuing.

Everyone, that is, except me.

For me, my university degree was and always has been significantly more than just a means to an end. While most see the subject matter as limiting and irrelevant to the working world, I view it very differently. Such thinking is at best unnecessarily restrictive and ignores the multitude of skills and thought processes that transfer seamlessly across the divide. Rather, the ability to function equally successfully at both ends of the scale (if such a scale even really exists) actually affords a unique advantage when it comes to modern business, especially within the ever-changing environment of software development. I hope what follows in the rest of this article sheds much-needed light on the popular misconception that English and coding don’t mix.

The study of English literature is, at its core, a deeply analytical process that hugely benefits from the sort of logical, methodical approach that more naturally leads most people towards programming. This is especially relevant to the world of software testing in which I am beginning my software journey. Both disciplines require an innate ability to scan vast and seemingly impenetrable sets of source material to pull out the most minute granular details that hold the greatest value.

In English that’s the ability to traverse a reading list as long as your arm for that one perfect quotation to back up your argument or the ability to spot a subtle but crucial shift in tone across the entirety of a 600 page novel. In testing, it’s the process of tackling a mass of code with one tiny bug in it, often as small as a single dropped semi-colon or missed bracket, that renders the entirety of the code temporarily useless. Such careful scansion and attention to detail are genuine skills but skills that are essential to students of both literature and computing alike.

Equally, essay writing and coding both begin in the same place with the same core problem: here is a blank page and a title/set of program requirements to work from. Go create something amazing that fulfils that brief. There are plenty of different ways in each to solve that core problem and whilst there is huge scope for creativity and flair in both, often a focus on simplicity and clarity produces the most effective end product. The tools at hand are different (although both rely heavily on languages with clearly defined rules, syntax and constraints) yet the mindset is exactly the same. Both require a structured approach, logical progression from start to finish and a clear understanding of the intended end result and target audience.

All that changes is the subject matter and the language in play. As such, the difference between writing a piece of good working code in Ruby and constructing an essay in English is no more significant than rewriting that same essay in French or transferring the same code to Python. The only thing holding people back from excelling at both is the extent of their particular passions and interests.

As tech teams continue to modernise their work methodology with the increasing popularity of the likes of Agile and Lean, the skills that underpinned my English studies are increasingly in demand in a tech-oriented workplace. Gone are the days when development and test roles were limited to just developing and testing. Now there is an ever-increasing emphasis on teams to take responsibility and self-organise, to present their work on a daily basis in stand ups and to weigh in with thoughts and ideas pertaining to the business needs of the company.

Since studying English involves a huge amount of solitary reading and writing and fairly limited contact time, the sort of self-motivation and time management required to keep on top of things are of just as much significance to this new tech work environment. Similarly the skills developed for presenting my ideas both to and within a group give me a definite headstart in the daily stand up. After years of being encouraged to actively contribute to group discussion and challenge my thinking with new and difficult ideas, I feel myself ideally placed to thrive in the open and collaborative atmosphere of an Agile office.

The only notable difference as far as I can see surrounds the nature of a completed project, and it is for this exact reason I have chosen to head down a more technical route in my career. Put simply, it pertains to the sense of satisfaction in a job well done.

I have always felt an immense feeling of satisfaction in creating code that works, especially on occasions where I’ve struggled and tripped up a few times along the way. There is a purity and a simplicity about a working piece of software that belies the complex mess of words and symbols beneath. But crucially, in that moment of completion, the program is categorically, undeniably, emphatically done.

Sure, it can always be improved, more functionality added, existing processes streamlined, code refactored and the UX enhanced. In a commercial environment, if a product isn’t continuing to grow, it’s already starting to die. But at each iteration of project completion, assuming success, then by every useful metric the product categorically and demonstrably does exactly what it needs to do in exactly the way it needs to. The sense of fulfilment and pride I feel in seeing a product I have created come to fruition and be quantifiably successful is significant.

Don’t get me wrong, a finished essay can also be a thing of beauty. I am immensely proud of some of the work I have produced over the course of three years at uni. But for me, reaching that same level of satisfaction is so much harder and rarer. An essay’s success is always up for subjective discussion; the same essay can be loved by one reader and utterly disregarded by another. There are always a million different ways it could have been written or structured better, countless background readings that would have made it more critically informed and thousands of alternative quotations that could have been used to take it off on new and exciting tangents.

An essay is an untameable beast that can very easily overwhelm and consume your sanity. To tame it is merely to decide that it has now been tamed; it’s done because I say it’s done and it’s good enough because I say it’s good enough. But neither decision has any direct bearing on anyone else’s sense of the same essay’s completion or value. You can decide to be satisfied by it at any given point, and you can place it generally in a vague hierarchy of better and worse in comparison to the rest of your output, but you know it can never be perfect. For me that is always a slight dampener, a little nagging frustration I can never quite escape.

I love reading. I quite enjoying writing too, especially now I have the opportunity to test those skills in new and different forms (like Medium articles!). I will continue to do both for their own sake. I also love big ideas and interesting discussions on just about anything you can think of. I don’t expect to be giving that up anytime soon either. But in my working life, a role as open-ended and utterly subjective as my English degree would drive me slowly insane. Rather, I am excited by the opportunities that lie ahead of me in software. I look forward to adapting and redeploying all the skills I learned in that degree in a new, fast-paced yet still extremely creative industry whose practical limits really do know no bounds.

That doesn’t sound like such a strange choice after all now does it?