The Journey to Wonderland
‘I imagine , right now, you must be feeling a bit like Alice, tumbling down the rabbit hole? ’
Let me begin with a confession. When I first saw blogging suggested as part of the Makers journey, I thought ‘no way. Absolutely no way. A candle scented like Gwyneth Paltrow’s vagina will explode in someone’s living room before I do that.’ But here we are — I am writing a blog post, and some poor woman in Kilburn had to deal with an ‘inferno’ when her Goop candle apparently consciously uncoupled from the laws of chemistry and physics.
My reticence was chiefly down to two reasons:
- I couldn’t see what I would get out of it
- I couldn’t see what anyone else would get out of it
As regards point 1, it’s become clear to me as I work through the Makers pre-course material that I need to write things down as I go. This usually takes the form of fairly chaotic comments and notes, like ‘ABSTRACTION. empty string vs. nil?? requiring libraries!!’
These are, self-evidently, indecipherable to anyone but me, and are not even that once a day or two has passed and I’ve forgotten what I was on about. It occurred to me that writing these things into a form that other people could at least in theory make use of would probably help me out, and (point 2) it might even help them out. In the absence of on-site learning and the diminished opportunity to shoot the breeze about the day’s topics over coffee or lunch, it might be a substitute for those kinds of conversations. And in any case, I realised it was rather bizarre for someone who has spent the better part of the past 4 years writing a PhD thesis on early 20th century French Surrealist erotic novellas, which, let’s be honest, will be read by approximately 6 people, to be worrying too much about the size of my audience. Plus, I just like writing. So why not write?
This brings me to my reasons for joining Makers. As I mentioned, I’ve just finished a PhD in French literature, and I come from a background in languages, literature and philosophy. So why coding? Why software development? It might seem like a bit of a leap, but for me, there’s a lot of crossover between the two things, and what I enjoy about them. Analytical thinking, strategising, balancing attention to detail with a holistic view, attention to readership or ‘user experience’— all of these things are essential to both program design and thesis design. My philosophy background, which includes formal logic, has made me a deeply critical thinker, the sort of annoyingly type A person who will challenge assumptions and dive into the tiniest crack or inconsistency in an argument. Again, not a terrible characteristic when it comes to writing code. Reading literature, like reading code, requires an application of determined focus and a willingness to question the basics, to extrapolate and interpret; at least, it does if you want to have anything interesting to say about it. And hopefully the ways in which learning and working with a foreign language are similar to learning and working with a coding language are demonstrably obvious.
As I came to the end of my thesis, I was considering what to do next. I didn’t want to stay in academia; I enjoy research, but I also get so much from working with other people. These aren’t mutually exclusive, but academic research is often very solitary. I also felt a need to be in touch with the ‘real world’ again, to be doing something of which the purpose and application was direct and clear. I firmly believe that academic research is of ‘real world’ significance, as is the pursuit of knowledge more widely, but sometimes the connection between the academy and real life can feel a little shaky.
I had always ruled out any kind of technical, STEM-adjacent career — I haven’t done Maths or Science since GCSE, a decision I now regret (I’m planning to do a Maths A-Level, hopefully next year). I love what I studied, but if I could go back I would have balanced it more. I felt compelled to make an all or nothing, Arts & Humanities vs. STEM decision because of the way that division was narrativised. It was only in speaking to a friend from my undergraduate course who’d become a developer that I realised that division was somewhat mythological. She was loving her job, and she saw a direct line between what we’d done at university and what she was doing now. Maybe this wouldn’t be such a crazy move after all. And in fact, when I thought about it, it made total sense. As a teenager, I’d been really into web design — while everyone else was drinking cider in the park with boys, I was making my Neopets’ pages as sparkly as possible and trying to build an online horse riding game (yes, you did read that correctly). All of that fell to the wayside slightly when I discovered that I, too, enjoyed drinking cider in the park with boys, but that interest in coding and creating and building things that work has never gone away.
This is really what drives me — I thrive off learning and doing, and channelling that learning and doing into making. I love feeling like I have a skill that sets me apart, that I can use to turn things into other things; insights and intuitions into thesis chapters, arrays, lambdas and methods into programs. But I’m also driven by always feeling like I could know more, by understanding what I can learn from and with other people, and by challenging what I already think I know (insert lengthy philosopher digression on epistemology and the nature of knowledge as justified true belief, or not, here). I feel such satisfaction in turning that development into something external, something that holds, that I can point to and say I had a hand in, but that I can also cast a side-eye towards as I think about how it could always be better. This is what the PhD process has been about for me, and that’s what I want to bring to Makers and becoming a developer.
Enough waxing lyrical. When I started writing this blog post I had intended to include my key takeaways from the pre-course and some specific personal lessons. But in spectacularly on-brand fashion, I got carried away, diving deep into my reasons for choosing software development. I’m glad I did; writing those out has been helpful. But this does rather fortuitously bring me to one principal lesson, which will be my mantra going into the first week of the full time course, and staring down the volume of material and enormity of things to immerse myself in:
SLOW DOWN. CHOOSE YOUR RABBIT HOLES WISELY.
Already on the pre-course, I’ve had to force myself to pull up and stop when I’m so caught up in one thing that I’m pursuing it at the cost of all else. I’ve recognised that learning doesn’t mean going at 100mph, and it doesn’t mean chasing every concept. Sometimes both of those things are useful, but you’ve got to know which rabbit holes to dive down and which to walk past or climb out of (or as Kenny Rogers would say, you’ve got to know when to hold ’em and when to fold ’em). And sometimes that means doing something that for a Duracell bunny like me is very difficult, and that the Makers meditation sessions will no doubt facilitate — taking a minute, or more, just to stop and breathe.
