When I did graduate work, I focused on languages.
No, not Python or C++.
Human languages, real languages.
But not modern languages where people speak them today,
ancient ones — Hebrew, Greek, Aramaic, Ugaritic, and others.
Like many, I ended up leaving the ivory tower for a mix a personal and professional reasons — not least among them, the declining state of the humanities.1
I haven't been in web development long at all, nor was I deep into a PhD (completed an MA), but I enjoy both spheres immensely.
All that being said, there are many soft skills I learned while in academia that have transferred well to web development and the business world in general.
In the humanities, writing is life. The mantra for post-docs is "publish or perish."
In the world of development, writing isn't given quite the same weight.
The basics are usually assumed — correct spelling, comprehensible grammar, full sentences.
Even those basics are not always observed or enforced, but most people are competent enough writers in our literate world.
What I learned from academia wasn't the mechanics of writing but how to structure a text and an argument, and most importantly, how to contextualize my writing.
Contextualization for a problem can easily be overlooked. Without proper context, the reason decisions were made or what the problem those decisions were solving can be lost or obscured.
Though not a priority in the moment, being able to write a well structured issue or report with context saves time for your future self.
Most developers are familiar with this skill. See Deep Work by Cal Newport.
It's not uncommon in the humanities for people to make entire careers writing about one narrow subject. Most branch out and write more generally in their field, but almost all I know have "that one" topic with which they're continually wrestling.
Of course most developers don't want to waste time so a quick search and click on the first Stackoverflow answer will often suffice.
That may work well for an obvious error, but when it comes to real problem solving, there is nothing like ruminating over a problem for days — going for a walk and thinking about it, pondering another solution while making coffee, shower thoughts, etc.
Programmers and professors know the joy of this deep thinking all too well.
I never understood why so many different grammars had been written on languages that hadn't been spoken in hundreds of years.
The same way I never understood why there were so many different programming languages and tutorials that all seemed to do the same thing.
The answer often boiled down to the theoretical framework they used.
As an example, it took me a bit to really get why
map functions were so loved.
I mean, sure, you can more write more concise code, but was a regular
for loop that bad?
In reality, probably not. But what matters more in theory underpinning
map — namely, functional programming.
When you get a grasp on a theory, you can start to understand why certain decisions were made by understanding how problems are analyzed within that theory.
There have been some drawbacks for each one of those skills:
- With writing, sometimes I add in too much information. Contextualization is great, but not if you confuse your coworkers.
- Thinking deeply is necessary, but sometimes I find myself taking too long and not just making quick fix and revisiting it later.
- Learning theory is helpful and has a lot of long term benefit, but it can feel overwhelming. Allowing my projects to dictate what I should be learning is more helpful.
I miss languages sometimes.
But, I've created opportunities to use my programming skills to do more with these languages than I could before. I can continue to create tools to help people with transliteration, creating flashcards, or generating unicode hieroglyphs.
Academia has done me well.
Share below any skills gained outside of the tech world that have benefited you!
site:chronicle.com "Humanities"and be dazzled by the depressing doom and gloom. ↩