I have been existing in a slightly strange space recently, because I have been simultaneously experiencing the process of learning from both ends. The past couple of weeks of work has essentially been spent meeting with the various graduates I supervise and helping them to develop their engineering skills. The past couple of weeks of the thesis has essentially been about text production and hence about receiving feedback from my supervisors aimed at helping me develop my English skills. Both situations have a number of interesting common elements once you begin to apply some abstraction, but of course, each also has unique features. Obviously, while I’m not without some skill in English, I am vastly more experienced in engineering, so can speak with a bit more authority on that side in my musings on learning.
My favourite analogy for an engineering graduate is a puzzle. They arrive with most of the knowledge that they need to be useful in the real world, but the knowledge is fragmented, so the main effort in the first year of engineering is in helping them join the dots, as it were, to use the knowledge they already possess. Given a simple problem, most engineering graduates can peck through their memory and find a solution. What they can’t necessarily do is string more of those pieces together. The most helpful technique I’ve found for helping them do that is to treat their problems with a higher level of abstraction. So instead of thinking about an “earthquake response” you think about a giant finger pushing your building. Now we have something abstract, but concrete, and as you move the finger to push on different parts in different ways you can start to see how the building responds, instead of trying to figure it out all at once. In general, putting aside computation is beneficial for understanding what computation is needed.
The reason that this approach can work as well as it does is because the problems we deal with are in a fairly confined conceptual framework. I’m fond of joking that structural engineering is simple Newton’s law F=ma, where a=0. We could summarize this as saying that there are only a few different fundamental concepts in play here, and to an extent, all of them can be brought in by judicious abstraction, pattern-matching and then un-abstracting.
A second major strand of the mentoring process is in providing access to my library of standard solutions. I’ve solved a lot of problems over the past 12 years, and many of these solutions can be re-applied with the serial numbers filed off. On the whole that means I can make sure they’re on the right general track at the outset of whatever problem they’re encountering, and I can then pick up the process again at the end to compare the details they’ve devised with the details I devised in my similar problem.
Once a graduate starts to be able to string their ideas together reasonably well, the emphasis shifts from finding a solution (that’s a given) to how that solution should be expressed, because there is a significant rhetorical component to both calculation and drawing. The focus of design documentation should be in the clarity of approach, rather than in an ability to meticulously track a series of numerical operations. It can often be easier to spot a mistake from a sentence, a 5-second sketch, and the answer than from pages of intricate accounting of this factor times that factor, and so on. Again, this is because many operations we do have a similar form internally, and follow a similar logic. Picking the right abstract concept at the start is most of the challenge, most of the time.
Beyond that, my role is to offer some insight and guidance on the profession as such and the engineer’s relationship with the wider world. This is essentially non-technical. I can offer some level of insight into how to structure a workday, how to prioritize work areas, and sundry other soft skills. I think I do okay at this, but I am far stronger on the technical content.
I don’t want to create too much of an impression that engineering is easy, because it is fairly complex, and the margins for error are fairly small. I am emphasizing that engineering derives from an interplay between specificity and abstraction, with abstraction often essentially taking precedence in good engineering. Having the right idea to start with is key.
So, on to my role as student, and my perception of being mentored. I want to think that English Literary Criticism is similarly reducible to a simple conceptual activity. In the case of engineering, it’s picking the right abstraction, and I want to think that the emphasis is opposite in English: it’s about closely and carefully applying an arbitrary abstraction to a given work.
Let me illustrate with two quick examples.
I wrote an essay on Rudyard Kipling’s Kim, a fascinating book that I love very much. I read the book a few times, decided that it was an interesting prototype of what would emerge later as the spy story, and wrote an erudite essay pulling out some ideas from this concept and looking at whether the concept fit, more-or-less. I got a C+, I think.
For my next essay, I wrote on The Wizard of Oz and Peter Pan & Wendy, running two parrallel close readings through the fall from grace, the exit from Eden. It was, in large part, sophistry. I got an A or an A+, I can’t quite recall.
What was important for the markers was the concept of having and testing a hypothesis, of some kind. I am not sure to what extent this is recognized as an operational mode for literary criticism, because in large part the way these results are represented is as an emergent feature of the text. Selective quotation, careful ideological construction, and long sentences are used to make the case. It is a very detail-oriented process, in a way which engineering is conceptually not.
Having said that, and used the word arbitrary above, it is not quite as simple as I make out, because a more highly abstract and more distant perspective can be used to provide a check. Disengaging from the details of an argument, like disengaging from the details of a building, is always a bit of a challenge, but there must be a certain level of support in the abstract case. It would be far more difficult to read Peter Pan & Wendy meaningfully through the prism of a critique of New Deal Liberalism than it was through the allegory of adolescence as a fall from grace.
This introduces a kind of meta-thesis that must be understood in order to choose a suitable thesis with which to read a certain text. This is where I think I have struggled in my writing this year – it is not all that clear to me why the current story-formula thesis is more appropriate than the in-fiction control of narrative was, but I have been gently guided away from this area, that was the nominal thesis topic when I started out. This is not a layer of thought that needs to occur at the level of the graduate engineer, though it does have a role in anyone developing their own approaches to problems, which is a part of the profession beyond CPEng, and in academia.
There is also extreme possible variation in the details of any given thesis. Conceptually, using the character of a spy as a prism for understanding the action in Kim is going to require different kinds of comparisons and a different level of reading to using allegory on Peter Pan & Wendy. The two different systems are operating on different component parts of the text, and at different levels of abstraction, with a different set of surrounding reference points in the wider critical discourse.
This has meant that the mentoring I have received has been operating at two different levels than I am used to providing in the mentoring I do, prompting this round of musings on the ways in which the two disciplines are different. The role of an academic supervisor also omits large parts of my role as an engineering supervisor – I don’t particularly need ethical instruction, or time-management advice, or a host of other things. I suspect that engineers are just as diverse in these matters as academics, and maybe a younger and less experienced person would need more in those matters.