Disclaimer: Spicy take incoming
We have surely all heard the trope that hiring in tech is broken at this point, but I recently listened to a discussion on David Farley’s Engineering room podcast with Allen Holub as the guest which really got the cogs turning for me and helped me to take a step back and reflect on how I got to where I am now. The podcast conversation took many turns, all of which were interesting and in some cases eye-opening but something that really stuck with me was an avenue that the pair examined and that was around hiring engineers in tech. As part of this, Holub posited that the drive to get more students in to STEM subject could actually have a detrimental effect on the quality of engineers that the academic institutions produce each year. The pair went on to discuss the qualities that they filter for when hiring engineers. It was interesting to me that technical skill ranked low on their wishlist and that strong communication skills were seen as more important. On reflection, this should not come as a surprise when we account for the fact that both Farley and Holub are prominent in the agile community and the manifesto for agile software development opens with the phrase “Individuals and interactions over processes and tools”. This is an interesting rabbit hole to explore more deeply here because I think we are already making steps to hire a more neuro-diverse group of people into the industry as well of those from different ethnic and economic background but little is discussed on hiring from a range of subject areas and areas of study, CS degrees being a pre-requisite requirement for many entry-level tech jobs.
I have been thinking on this ever since listening to that discussion as I have done plenty of hiring in my career although until recently, I was not hiring for Developers but Analysts. I have always tried to make interview processes about an open discussion to ascertain whether I could work with the interviewee day to day and to see if they are enthusiastic and malleable enough in order to pick up the technical aspects of the role rather than raw technical skill.
So with that said, why do I think that an English degree can be useful for a career as a developer? (I promise I’m not just trying to convince myself that my degree is not worthless)
Firstly, studying English encourages students to form and present opinions on a range of topics backed by research and autodidactic learning rather than rote repetition and retention. This is useful for many reasons, not least in choosing tech and tools for solving problems but also selling those decisions to the business and decision makers. It is also helpful when explaining technical topics to a non-technical colleague or stakeholder where the explanation can make the difference between a good and bad business decision that can have significant impact to the company’s bottom line. In short, English degrees create strong communicators, I don’t believe this can be said for all degrees.
Another aspect of my skills that I saw develop as a student of the English language was proof reading. I see this as my superpower and has saved me and my team pain on more occasions than I can count even in the last year alone. Reviewing Pull Requests becomes a lot easier and less error prone (dare I say it even fun) when you have a keen eye for a typo.
Finally, and I think the most important skill of all that I can take from my English degree into my work as a developer is the ability to write prose. Uncle Bob amongst others has written on the importance of optimising for readability and this is something I try to be aware of when writing and refactoring my code. If I can make my code read like natural language, this makes it easier to understand and maintain for everyone involved in the project. Even seemingly small things like extracting a well named function to use in a conditional or renaming a variable to make the code easier to grok is a win as far as I’m concerned and having a strong grasp of the English language makes this exponentially easier. Another David Farley quote that springs to mind here is that “if you can’t trust a developer to write a good comment, you can’t trust them to write good code” and this wrings true for me. It reminds me to take a step back from time to time because if I can’t succinctly explain a problem or task, I’m not in a position to start writing code and need to do more communication and iterate on this before I open up a text editor and start my Guess Driven Development loop of Red, Red, Refactor, Still Red.