Why I’m writing this

Extracting something interesting to say out of what feels like a good - but perhaps vague - initial notion can be tricky and frustrating, especially for someone like this engineer trying to be philosophical about the engineering life. That’s what happened when I was working on a now postponed post: I found myself getting stuck in the descriptions, on the surface, without finding a way to get satisfyingly deep into what I was trying to say: more drifting than drafting.

Then I remembered another (unfinished) draft from an (unfinished) series on engineering tools and I thought it time to put that tool - the Ishikawa diagram - to use.

The Ishikawa diagram

Also known as the fishbone diagram because of the way several themes jut out from a central theme’s spine, this isn’t as uniquely an engineering tool as the FMEA, but it is much used in industrial settings, mostly in the context of quality investigations. Looking back, I found a wry post of mine about it from back in 2012, where, whilst being more fixated on the overly literal depiction of the fishbone diagram, I listed out the typical topics for a quality investigation (the several ‘M’ words like “Machine”, “Manpower”, “Metrology”, etc, as titles).

Fundamentally, it’s about seeding ideas to be condensed around common themes to ensure that nothing obvious is overlooked when searching for a root cause. It’s important to note here that it can also be an efficient tool, in that clearly irrelevant or non-contributing aspects can quickly be disregarded, allowing focus on the trickier stuff.

The Phishikawa diagram…

… or “Phishbone” diagram, is the philosophical version of the original. Its bones consist of key philosophical themes to aid in the search for the roots of the topics we want to consider. In this case, it won’t initially be very efficient, as I’ll need to spend time with each topic, these being:

• Ontology (attempting to describe how a topic is)
• Epistemology (understanding what we can know about the topic)
• Acting and working (understanding what modes of action and knowledge are involved - based on Aristotle’s concepts of poiesis (making) & praxis (politics))
• Hermeneutics (how we interpret texts and artefacts resulting from this topic)
• Phenomenology (how we experience this topic personally)

This is what it looks like, in its first iteration:

Continuing my observations on being a working, playful engineer: you can read the introduction in Part 1

Time flies when you’re in the lab

I recently read, in a borderline mystical article about the Taiwanese chipmaker TSMC over on Wired, the phrase “time flies when you’re in the fabs” (production plants where microchips are fabricated). Substitute the ‘f’ in “fabs” with an ‘l’ and you have the same for me in the lab… sort of.

In that article, the time-flying stems from the sort of sensory overload we experience when visiting a new city or a factory for the first time: the quantity and intensity of new inputs and interactions can overwhelm our mental processing capabilities and it’s tricky to know where to focus our attention.

For this effect to take hold in a calm, familiar lab we need other stimuli, something unusual to happen, to kick us out of the routine and into a mode that could (until a technician reminds us) lead to us forgetting that it might be lunchtime. We need play.

The lab for the development engineer

It perhaps doesn’t sound right to associate a lab with play, this agile alertness that brings joy and satisfaction to an activity, and there are certainly some instances where, as you might expect, the conditions necessary for play simply aren’t there: we’re repeating a totally standard test on standard parts for re-qualification. In other instances, excitement occurs, but not necessarily play (quality investigations spring to mind, alas).

For me it was as development engineer that my playful relationship with the lab really became most apparent. Setting out to produce something new from an initial idea gets the creative juices flowing, the mind whirring. Extending this into the lab is brilliant: not yet knowing if parts can be tested with current equipment, not knowing what the results will be (even if we have hopes or technical expectations for what they should be), uncertainty as to how representative of a potential final product the initial prototypes will be all gets us thinking, imagining, tinkering, bouncing ideas off others in the team. At this exciting stage we’re a long way from expecting pass/fail reports or sometimes even answers: we’re finding out what the questions should be, we’re in the phase where interesting results are to be found in the realms of “promising,” “so-close…,” or “so far off…": results that lead to further ideas and testing.

Playtime!

These are my most “alive”, most playful moments in the lab, with multiple phases and objects (in the grammatical sense of people and things) of attention: chatting with technicians, handling parts, checking drawings and the test rig, figuring out how samples might be mounted, whether we need new fixtures (if we do, and we need to order something, playtime quickly ends!). The lab technicians may have encountered similar ideas in the past and warn what their weaknesses were. This is where the ‘plan’ (the official test request that I wrote back at my desk, in the past), meets a reality which is starting to become “now”, and need knocking into shape to bring closer to practical reality.

Starting the test entails switching attention from the personal and the physical to the informational: whilst still operating keys and switches and clicking a mouse button, still discussing with the technicians, we’re opening the appropriate programs, ensuing all the settings and parameters are right for this test (they may be totally custom, or tweaks of some existing presets), priming the data logger to start upon a certain trigger signal, and then pressing some kind of ‘start’ button to run the test.

Finally the test begins: I’ll have my hopes, fears and expectations, and (if I’m in the lab whilst testing is under way) I’ll be weighing up the results against those expectations as they come in. I tend to be unable to avoid interpreting every single result as it comes in, pondering already - too soon, but in preparation - their meaning, and of potential repercussions or next steps in the product’s development, whilst actively reminding myself (part of an engineer’s training and experience) to avoid reading too much into the insufficient data that we currently have… If I’m helping with the test (usually a bad idea, but sometimes necessary), I’ll be petrified of missing a step, but too distracted by the results to be able to calmly concentrate on my tasks, so sometimes I’ll make mistakes. Equally, though, if I see a totally unexpected result come up, I’m on hand to discuss it straight away with the lab technician, ready to test hypotheses and to come up with a plan on the fly.

For very slow tests (the archetype for me here being corrosion testing), those doubts and expectations surface from time to time at unexpected moments, the spirit of the test spooking me from where I sit, calling me back to the dungeon - I mean lab - to check up on the parts, peeking into the chamber to reassure, or to terrify myself, before the official end of the test, all the while being aware of the suspicion of influencing the test by the mere peeking inside…

This is all part of the game, aspects of play.

Not play

Typically, for me, the sense of play is over long before the full test is finished: testing itself quickly becomes routine and requires that different mindset and expectations of a technician. As hinted at above, a key difference between someone like me and an experienced technician is that they typically don’t let themselves get distracted by results, and can - we could say stoically, though it often seems more simply to be their nature that drew them to this job, rather than any additional philosophical system modifying their behaviour - just plough through the testing, seemingly effortlessly concentrating on testing each sample correctly.

This raises some interesting questions about games and play: surely there are games that require quiet concentration, the ability to avoid distraction and still be able to react to variance? Yes, of course! My counter to this point is that, if the prior play has been successful, and the test runs well, then you could put any practised technician in to run the test itself, without any knowledge of the parts or the origin of the test: it’s routine that wins, not reactivity or any particular alertness.

Indeed, under certain circumstances, I would run the test myself. There are aspects of this that I appreciate: handling the parts, knowing their type and expected performance, I observe and register many things, almost like a craftsman; the same with the test rig and mounting the samples for each test. Yet this doesn’t feel playful to me: it’s careful and precise, but doesn’t require the alertness or the ability to bring in factors from all sorts of sources for it to work. It just does work, and can (should) be a bit of a plod.

Usually, the end of the test also doesn’t feel like play: it’s mostly loosening things and removing samples from the rig. Typically, we’ll look at a few of them to see if anything unusual happened to them, visually; if it’s an unusual batch, then I’ll keep them all for possible analysis afterwards. It’s the analysis, interpretation and presentation of the results where the playful can re-emerge.

The philosophical playoratory

It’s in such an appropriately equipped, ideally local and freely accessible lab (rather than an external test centre), where you know the colleagues and can take the time to discuss things with them, that a lot of what makes engineering so appealing come to life: bouncing ideas off each other, deciding what tests to run on which parts, what equipment to use, who would be the best person to do the testing. Phrases like “oh, let’s try it in there” or “could we perhaps…?” or “let’s test a couple of parts, see where we stand”, or “how do we get this to fit?” and “do you think we’ll be able to see if…?” represent play in the lab.

Analysis of the data or of parts after testing can also be playful, the classic example here being the microscope: “check there,” “zoom in to that”, “measure that bit there” - but of course with the same phrases being applicable to charts and data - always trying to figure out meanings and implications.

When I consider my interactions with the lab, things get philosophically complicated and interesting, with multiple relationships and perspectives manifesting at different phases during a test, and, sometimes, all at once. Here’s a list of the semi-philosophical aspects that flicker in and out of attention in the lab context:

• My relationships with colleagues
  • Philosophically related to politics, practice and ethical action
• My relationship with the parts
  • Those parts and their multiple meanings and implications are present physically and (differently) in my mind. In both contexts are they real entities on which I imbue real concerns and hopes. I sense them and I imagine them.
  • Philosophically related to the perspectives of…
    • practice and technique
    • phenomenology (understanding how we experience and interact with others, along with borderline metaphysical considerations of “reality”)
  • ontology (understanding what is, and how it is)
  • epistemology (knowing what we know about the part, and what we still don’t, and want to know)
• My relationship with the test equipment
  • direct (if I do the testing myself)
  • indirect (if the technician does the testing for me)
  • knowing its strengths and weaknesses, relationship with “real world” use
• Philosophically related to…
  • phenomenology
  • ontology
• My relationship with the test process / procedure
  • determining steps in advance: planning
  • being alert and open to possible changes as they come in
  • action
• My relationship with pretty much the whole of history (or at least the history of science and technology)
  • how we ended up with these machines, parts, means, methods and levels of understanding
• My relationship with the “background technologies”
  • Paper, screens, mobile phones, furniture, buildings, infrastructure
  • Fans, coolers, data networks of the equipment being used
  • Test rig consumables
• My relationship with the data
  • Philosophically…
    • hermeneutics
    • epistemology (how do I interpret the data, what knowledge and experience do I already have that permits me to understand what the data is telling me in this particular, hopefully productive, way)
    • phenomenology (how am I viewing the data, how are they mediated)
• The overarching experience of testing
  • phenomenology
• Full suite philosophy

As we can see above, the lab - and engineering - is full of the key perspectives of philosophy (that I’m aware of, anyway, discounting metaphysics):

• Hermeneutics - interpreting requirements, procedures and results
• Phenomenology - “feeling” and experiencing the parts, through your eyes and modulated through instruments
• Epistemology - assessing the current knowledge about a thing, trying to figure out what’s not yet known, and how to know it, how confident we can be in that knowledge, and how to deliver that knowledge to others
• Politics and interaction (and a kind of technological ethics) - dealing with lab technicians, lab managers, getting timing commitments or confirming resources, dealing with problems
• Maybe some ontology, as an overarching concept? What exactly are these things and tools we are dealing with? How do they exist, what becomes of them during and after testing? What are our affordances, what can we use, manipulate to our advantage, ensuring power and data connections, temperature conditions, etc

These perspectives all intermingle, and attention flickers between them. I, as a non-philosopher engineer, have a lot to learn from them, which is why I’m here, writing this!

Play anywhere!

This extended reflection on my experiences in the lab is only one example of how work-time play can arise. The phrase “productive meetings” doesn’t need to be an oxymoron: ideas really can arise out of playful action, even in a meeting environment.

Don’t discount non-work play at work

Another form of play - equally important, in my opinion - is recreation. Ultimately, this is about restoring body and (in our case, in the work environment, more significantly) brain to be ready for the next pulse of work. Our brains really do get tired, gum up with waste chemicals that need removal or simply need more fuel, after all. But we, as humans, also need to tend to our groups, teams and societies - so that lunchbreak the technician reminded us of earlier is important in this way, too.

Documentational drag

In engineering, as at home, playtime is often over swiftly. Data gathered from the tests needs to be summarised and reported; completed, those reports have to be saved in the appropriate library for future reference - tagged and searchable so that future colleagues have a chance of finding what their predecessors got up to in the dim and distant development of those tests, products and processes. And, of course, the physical needs to be tidied up, too - a fundamental part of play, but not, as far as I experience it, play!

From play to mastery

Another aspect to consider is that the goal of work is mastery: knowing what to minimally adjust to achieve the maximum desired effect. Mastery is a calmer version of play, secure in the knowledge that what you’re doing is right (and good), but retaining that awareness and reactivity to adjust to any small deviations.

Just as there are various perspectives to focus on whilst mastering a musical instrument (sound, agility, improvisation, etc) - or even, come to think of, a measuring instrument, there are ways of mastering engineering topics and systems that aren’t purely technical, but require that playful agility, that personal phronesis, way of acting, that has become such a key part of my thinking on engineering.

Once mastery has been achieved, though, the goal of a company is often to move back beyond mastery to renewed play - to build on the already-mastered to expand its competencies and to stay ahead of the market game. This is an institutional challenge that goes beyond the individual, but it relies on individuals to recognise that necessity and not to succumb to the deadening constraints of overspecification and the mere passing of audits.

Getting back into the game

I’d like to end on a personal note: as I mentioned in my penultimate post, I’ve been between jobs for a while. I can now report that as of May 2023 I’ll be getting back into the ring, in a new arena, with completely different products to those that I used to be involved in making. Fortunately my new employer recognised the skills and experience that I will bring with me to their game, and I’m looking forward to making use of them once more. But most of all, I’m looking forward to playful engagement, moving things forward with a new team, in perhaps unexpected, but fruitful ways.

By “play” I mean, of course, “work”, but in a certain mode, which, because it’s work, isn’t always fun but can be, more significantly, very satisfying.

What is play, and can it work?

Thinking back to an episode with my daughter from a while ago, I recall fondly how she wasn’t in a good mood - well, OK, that’s not the fondly remembered part; what is, is that we changed that through play. I joined her as she sat listlessly on her bed, surrounded by toys: a few cars, horses and an array of some of her smaller cuddly toys. We both just sat there, amongst the toys, for a little bit - at least she didn’t send me away. Then, on a whim, I grabbed a car and started driving it over the mountainous terrain of her duvet. The car drove up a ridge too fast and flew into the air, now swooping and banking in all of the suddenly available three dimensions. My daughter responded by reaching for a toy horse, which leaped into the air to chase the thieves escaping the scene of their crime in my car. The glint returned to her eyes.

From there the story took many magical twists and suspenseful turns, including more chases, clever distractions and arguments, as well as frequent restorative and reconciliatory cups of tea amongst the protagonists, until, at last, the horse rustlers were apprehended and promised not to do that again…

Thinking back to an episode with a supplier, I recall fondly how one of their process had proven to be less stable than expected - well, OK, that’s not the fondly remembered part; what is, is that we changed that through… well, in an engineering sense, it was through play. We sat in the meeting room, surrounded by parts, flipcharts, whiteboards, the projector and tools. Then, on a whim, I asked about one particular aspect of the production line; the supplier responded with details on that, which then raised more questions, leading to a dash to the production line itself to see for ourselves, then to modify and tune parameters, replace tools, take parts into the lab for testing, eager for results and direction.

From there the story took many developmental twists and political turns, including more trials, confusion, argument, and restorative cups of coffee amongst the protagonists until, at the end, the process was stabilised and the supplier promised not to do that again…

What just happened?

What unites these two episodes despite their very different contexts is play: both involved getting involved and getting caught up in a situation, openly and staying alert to sensing, reacting to and guiding what happens. Play is by no means a passive or “useless” activity if it’s guided towards the matter at hand: the brain is whirring away looking for signs, adapting, trying, sometimes failing (I got told off by my daughter for attempting to use a teddy as an all-powerful giant to smash open a cave), but quickly adapting again to find something that works to maintain momentum.

Play that lab report

‘Play’ has a childish ring to it, connotations of a lack of seriousness, of ‘wasting time’ on Wordle rather than writing that urgent report, and it remains true that the playful mode isn’t suited to all engineering tasks (filling out Bills of Materials springs to mind). But, with play, we can allow ourselves and our teams to widen the mental net, to get things wrong to then get them more right, to find more efficient workflows and to make work simply more fulfilling, whatever the task.

Indeed, if you think about it, what is report writing but an exercise in language, and what is language but one of our most fundamental modes of play? In writing, you’re looking for words, trying out phrases, sorting and re-sorting the order, searching for alternatives, yearning to get past that frustrating and tantalising “tip of the tongue” barrier, whilst still progressing the word count or in editing afterwards.

One level beyond that of language being a form of play is to treat philosophy as play, too, as Joseph Dunne points out in the introduction to Back to the Rough Ground:

philosophy can seriously address practical issues and be a form of play.

Later on, he expands on this thought:

Philosophy is itself a practice, and, as in the case of any other practice, it is only when one gets caught up in doing it that one can learn to get out of it what it can give

Being aware of what Dunne means by “a practice” is important: it’s that non-technical, non-prescribed art of action and interaction: it’s not-checklists (but it can be involved in creating checklists in the first place!) Play, in all contexts, is about agility, being fleet of mind, and being prepared to expand horizons of opportunity.

In my next post, I’ll give an example of a particularly rich source of ‘play’ from my experience, namely the lab.

Until then, keep playing!

I am, for reasons beyond my control, at present - yet hopefully “only” - between jobs: being out of my last job is a fact, and finding a next one isn’t (I’m working on it, and have a couple of potential leads), so uncertainty abounds.

I posted about how I feel about this situation on my personal blog over at Diversions Manifold. The philosophical aspect that I want to reflect on here is, now that I’m not working at an engineering company, whether I am also (again hopefully, only temporarily) out of engineering, and, because of that (temporarily) not an engineer.

Staying engineer

Without right now wanting to go down the rabbit-hole of trying to define what, exactly, an engineer is, we can at least posit that the two (engineering and being an engineer) are different states (being and doing): so I am and remain an engineer, but I’m not practicing it.

Briefly to the personal, I’ve been out of my job for nearly two months now, and it’s been tougher than I had expected. All that searching for appropriate new jobs, updating CVs and cover letters, preparing for interviews, accepting rejections, and the frequent switching between hope and - well, not despair, exactly - but certainly concern for the future, have taken a higher than expected toll on me.

But all that work on the CV, tuning each cover letter for each application and now having had a couple of positive-feeling interviews, has made me aware of the wealth of experience I can count on. This experience isn’t just “past”: it now constitutes part of me and my neural networks, enabling me to act in my own unique yet “engineeringy” way. Each item on the CV recalls the nous and the feel I have for the combination of techne and praxis, for the technical and the playful in my profession. Significantly, they all still feel “live”, accessible and deployable for whomever and wherever I end up working with and for. Each item hides, or signifies, a story. Not just “work experience”, but real struggles, achievements, lessons learned or buried for possible future connection to another event: bruises and scratches (usually suffered by mouse and text) that have formed me. Those learned paths haven’t, I feel, become impassable and atrophied in those two months out of practice.

Those same experiences are also devilishly difficult to describe to someone in an hour’s online first interview…

Hearteningly, I find myself looking forward to making use of those skills again, and haven’t entertained thoughts of trying out something else entirely.

So, to me, I’m still an engineer, and potential employers seem to concur. The other question was: am I out of engineering?

Not quite engineering

The one tech-adjacent hobby that I’ve been working on during my gardening leave that could be considered to be “engineering” is resin 3D printing of mouthpieces for brass instruments. Actually playing those instruments (in my case, the trombone), is clearly a different category of activity altogether - and combining the two is a fascinating pursuit.

At present, I’d say my 3D printing is at more of a craft stage than anything engineered. This is not to denigrate crafts at all: they most certainly require ingenuity and a feel for both the materials and what is to be achieved through them; they rely on internal impressions and learned pathways for the craftsman to interpret and “feel”, then to act - or react - at each stage of the process. In all honesty, that also describes rather a lot of engineering: the spectrum of crafts does overlap with that of the technical as well as of the purely artistic. In my case, I’m only now beginning to settle on a half-way reliable print setup that allows me to make design changes and print them without the permanent fear that they’ll fail; concentrating finally on the part itself without worrying about the printing process that goes into producing it.

So, although my equipment and materials have all been engineered to a high degree, my own use of them is not at an engineered level. My craft has not yet been elevated to engineering (I say this whilst bearing in mind that many crafts would be smothered by engineering).

My engineering self does have an idea as to what’s required to make the whole setup more engineered: having a good, reliable technical setup, selecting the best materials for the job, developing reliable tests and parameters to measure and compare each iteration, and gaining confidence in the information available to me.

Just that first point is complex enough, involving optimising factors like print orientation, support structures, UV exposure times, resin bed tilt rates and (quite key) temperature control. My current settings - and challenges - have all stemmed from not-quite-understanding what affects the quality or success of a print.

In philosophical terms, then: epistemologically I’ve been floundering to find the knowledge that will lead to success, still unable to transition between types of knowledge, from having a “gut feel” to a theory and procedure that will - all other things being equal - guarantee a successful print and product.

This is a very common engineering dilemma. We have nous - an idea that something works - which we can even specify in terms of parameters that should lead to a quality product, but we don’t usually delve back down “to the atoms” to understand precisely what’s going on in either theory or practice… until it goes wrong, our assumptions are challenged, and we have to learn new details.

Ontologically, it’s fascinating to recognise that I have converted concepts and ideas into 3D CAD files into sliced printer files into print jobs into actual parts (and surprising amounts of waste), then, on the basis of trials, updated the CAD files to continue the cycle until - still a goal - I have a satisfactory product… for me. After that, I’d have to be able to translate those parameters for other players, and players of other instruments.

Phenomenologically, I have interacted with computer and machine user interfaces, (hermeneutically) interpreted 2D renderings of non-real 3D objects into mental “understandings”, and then, finally, felt, tried and (unfortunately, in many cases) smelt the final product as they emerged from the whole production process, leading to a search for less pungent, officially biocompatible materials to work with, as well as for the “perfect” design.

Sounding it out

Leading on from the phenomenological experience of the part, the “true”, or “real” end of each 3D print is a satisfactory quality of the mouthpiece that’s been produced. Here, at the time of writing, I’m leaning heavily on my “ear” and on the personal feeling of playing a new, plastic mouthpiece, all the while comparing it (is it “better”, or “worse”) to my standard brass mouthpiece, to previous prototypes? That’s not an “engineer’s” way of understanding quality, and it’s far from being scientific. So I’ll also be searching for ways to standardise tests (involving microphones and sound analysis software, for example) which will still, no doubt, depend on me playing the instrument with the new mouthpiece in it. Can I define a standard embouchure and air pressure to play even a standardised sequence of notes in exactly the same way for each variant, like a golfer honing their swing?

Probably not, but I’ll try.

That’s the engineer in me knowing what’s required - but not yet engineering.

Admin it!

One aspect of engineering that I’m very far from with this hobby is the whole admin, bureaucracy and documentation aspect of engineering. Ultimately, engineered products are to be used by customers, so must meet norms and regulations, be economically viable, environmentally acceptable. So, even if I did end up with a technologically proven mouthpiece design, I have the feeling that, without a company behind it, it’s still a craft. Is engineering ultimately also an economic activity? It’s something to consider!

Working it out

Practically speaking, and to summarise: I’m out of engineering, but I still know what it looks and feels like, and feel able to rejoin the ranks of the engineers. Just wish me luck on that front: I don’t want to have to be too philosophical about being out of work…