Sebastian Abbott

Ship it

Finally! Our long-awaited prototypes have arrived from the shop, and they look presentable. All they need now are some measurements at a specialist lab, additional treatment at a coater or, if you’re happy to chance it, assessment by a customer… and our enthusiasm hits a wall as we realise what comes next. With a sigh and a last sip of coffee for what will probably be a while, we steel ourselves and enter the arcane world of packaging, form-filling, cost centre allocations and handcarts - namely, shipping.

There will be boxes to find to fit our goods, filler to prevent rattling and damage, packing tape, too (bonus points if you have one of those hand-held dispensers with the jaggedy cutter available); no doubt you’ve already equipped yourself with ruler and scales, plus pen and paper to jot down the parcel’s weight and dimensions for when you have to fill out one of those shipping forms later. Perhaps you’ve been thoughtful enough to write an accompanying letter, and alert enough to have printed it out, signed and even put it into the box before taping it up. But you didn’t just seal up your contact’s details that were in the letter into the box, did you? You’ll need that perspn’s email address or a phone number for the form, too.

With steady resolve tinged with trepidation, as a supplicant to a sage, you pile your slightly too heavy to carry box and sundry notes and scraps of paper onto a cart or trolley, and trundle across site to the shipping department, where I can only wish you the support of willing and contented colleagues. Form filled out and ready to go? Great! But no! For shipments to other regions, you’ll have to slink back to the office to sift through and decipher mysterious customs categories under which to declare our goods, fearful of the potential delays and further costs that will be incurred if you get it wrong on the additional forms you took back with you, or had to find somewhere on the network and print out yourself.

And on it goes - finally getting it sent out, obtaining the tracking number to email to the recipient, perhaps monitoring the shipment over the next day or two. It can be exhausting, and it feels… well, perhaps a bit mundane.

Engineering is (largely) mundane

Packing and shipping is just one example of the mundane that deflects from our engineering, dragging it back, we feel, into some kind of bureaucratic swamp from the blue skies of thinking that we strive for. There are plenty of other such activities: receiving and booking goods and prototypes, planning business trips, filing expense reports, logging IT tickets, organising meetings (attending meetings!) - they can all feel like disruptions to our engineering flow: we’d much rather be dreaming up or working on solutions to immediate problems, than “just” plodding through this admin and bureaucracy.

But what if these actions are also engineering?

Even if we don’t possess the mindset to really make those “engineering-adjacent” activities our own (thank goodness there are others who seem happy to fulfil those roles), without them our intended products - just as clearly, in the extreme case, as if we were to forgo CAD modelling or simulation or validation testing - simply wouldn’t get made properly. Which, if engineering is the fulfilment of technical intentions, also makes them part of engineering.

Have someone else do them?

There are companies (German Mittelstand companies, for example) where someone else does all of that administrative stuff for you - assistants to make the calls, box the parts and get them shipped. There’s a case to be made that that’s actually the most efficient allocation of resources. But it is, fundamentally, the same thing: we need and expect to eventually get the results, and when have we ever been able to mutely hand something over to someone and expect the correct outcome? We can’t seriously do that: we have to specify our needs and transmit them to our helping counterparts.

That, too, is “a mild case of” engineering: we specify something that needs doing, and the better the specification, the more likely it will be that the output will match our expectation more closely.

Feel the community

Engineering is part of life in a company. Each individual action we take as engineers and the sum of them all reveals the realities of that company life, how everything fits together, or doesn’t quite; how the company tries to protect itself from the risks of error or fraud; how we’re all in the same boat, operating often ridiculous-adjacent bureaucratic systems, often without a clear reference guide, with not always clear outcomes - and how it can all make more sense and be more engaging when everyone pulls together with humour and good grace.

Feel the project

There’s also something in the argument that it’s better to “feel” the product, to really experience it as it develops within the project. Wrangling parts into boxes, or fitting them into test equipment, or visiting the production line can bring you closer to those technical objects, linking what we see “through the screen” to the physical perspective whilst engineering what we engineer.

In Eric Berger’s book Liftoff: Elon Musk and the early days that launched SpaceX there’s quite the implicit critique of a particular type of engineer:

At some government labs and large aerospace firms, an engineer may devote a career to creating stacks of paperwork without ever touching hardware.

Those stacks of paperwork (or Excel files, PowerPoint presentations, but also CAD designs, FEA simulations) help the project to progress, of course, but at the expense of feeling the product.

At least activities like booking travel, which, granted, truly isn’t that much of an experience, give you that sense of breadth in the company - what it all gets up to to ensure its progression - and the travel itself is an experience, even if it does involve sitting around in other forms of moving boxes, most of the time.

What this all drives at is what philosophers call the phenomenology of our undertakings, the experiences and how we “feel” it all through our senses, as engineers, as humans.

Isn’t it all engineered?

The thing is: what objects and systems have we been using all this time? If we think about it, don’t they also come across as being engineered? They manage inputs and outputs, capture certain forms of logic and reason, and bring us a step closer to our goals, even the shipping systems and the forms and the costing systems. They have all been designed and built (or have evolved) for robustness and accuracy, from the humble cardboard box which has already been shipped five times, to the robust tape and the goods inwards receiving systems - they are all, too, the result of design and a form of production, presentation to the market and were deemed - by whom, exactly, under what criteria? - good enough, fit for purpose.

So, whilst the “control switches” are different to the ones we use in our daily work, they are there, they serve our purposes and help us to achieve our goals, just as much as Excel, PowerPoint, and our favourite CAD and FMEA tools.

Engineering contains the mundane, the mundane engineering

All of these mundane actions can be treated as being “of”, as well as “along with” engineering. There’s the case to be made that, as a result of the this, we should treat them with the same mindset and discipline as we treat our “true” engineering activities. We may not like them as much, or be as good at them as we would like, but with that mindset of valuing those actions, we can become better at them, and our products better with them.

The artistic flipside

The counter case would be that of course we need these systems, just as trains need rail and our PCs electricity and cloud servers. They are infrastructure: complex and important though they may be, they are “just” infrastructure to us, when we’re engineering: background. Logging in to our workstations in the morning isn’t “engineering.” It’s just preparatory work, using the infrastructure around us to elevate us to the correct, expected level of work. It helps to get us into the zone that we need to be, focussed on the task at hand, tools usefully evaporating away and around us so that we are only seeing and interpreting our work towards the product.

It’s perhaps like a sculptor who needs the block of marble to be there where it can be worked on, but doesn’t “care” how it gets there. Only when focussed on the block and the form steadily being revealed; when setting the hammer and chisel at the precise angle and gauging the required force to chip and glide away: only then can the artist be the artist, truly.

Of course the artist needs to purchase the marble and to be paid for the work, of course tools need to be maintained or replaced, but those are non-core activities that could also be done by (skilled, for sure) lackeys and apprentices.

Perhaps that’s the true test of what is engineering. Could someone who gets our parts shipped out take over our work? Could they really interpret what we see, feel what the right course of action should be to resolve that tricky little set of clashes or contradictions that confront us? Could they even see that there is a problem there at all?

Mastering our metier and our tools gets us into our bubbles, focussed on the value that this product should gain. Ideally, we could murmur an aside: “that prototype needs to be shipped out”, and an AI agent would fill out the forms for us, ask someone to collect it and box it for us, whilst we continue working on the next phase of development.

But that would also mean cutting ourselves off from the rest of the company, and the messy humanity that that entails. It’s finding the balance between the two that makes engineering - despite its technicality, its techne and its hermeneutics - nevertheless a human activity, full of politics and phronesis, to use terms that bring me right back to the beginnings of this engineering blog, and to Aristotle. As two of the sub-headers above intimated: it’s about feeling our work, our lives, and making them not just “value-add” but also worthwhile.

Today’s Guardian crossword puzzle brought up the word “incipient”, which is a great fit to my previous post, What we engineer, referring as it does to something developing or beginning to happen.

Incipient was the clue - the answer was “inchoate”, which is more about something just begun. These are words that I’ll bring with me on my continued slow-plod thinking about engineering.

It’s almost as if René Magritte was thinking of engineers when he created his famous painting The treachery of images, famously undertitled Ceci n’est pas une pipe, which I am sure you will recall looked almost exactly like this:

Is it a pipe? In the minds¹ of most engineers, it both isn’t, as Magritte insisted, and it is, and much more besides.

We’ll certainly talk about and refer to it as a pipe at work and - probably very briefly - if family or friends ask about our work. Since pipes rarely occur by themselves in a system, it will carry a distinguishing name, too: the feed or return pipe, for example; left or right, front or rear; high-pressure, low-pressure; gas or liquid. It might be called synonyms of the word “pipe”: tube, line, conduit, etc; it might be a hose. With such distinctions in the name, we as humans automatically grant it an identity that turns this idea of a pipe into an individual. During project meetings, we’ll talk about its status, open issues, timing, costs, suppliers and so on, all as if it were an object we could reach out to, pluck from the bill of materials, and place in front of us on the table. That image of it firms up the identity, even if we know that, in reality, it won’t be a simple, dull grey.

We’ll talk about its data as a 3D model, too: who needs to know what about it, how up-to-date and settled or mature it is, where the data is stored and whether it has been synchronised with its counterparts in the rest of the system.

Ideally…

Clearly, my pipe doesn’t yet contain enough information to be useful: it’s an idea or a concept that hints at what could be. Right now it can’t be connected to anything, not even virtually, as it lacks important features such as endforms and fittings, or any information as to what it’s to be made of.

It lacks itself, in many ways: it’s incorporeal, a “mere” representation, both of what it should be - a pipe - but also of what it isn’t: a pipe, yet. It is made up of (digital) bits and (human) ideas, not atoms, but it’s buzzing with identity and potential. In our minds, that image and its identity are hooks on which to hang further data and information that help to refine our engineering interpretations and definitions of it, to bring the pipe as we see it now closer to matching what we intend it to be.

As the researcher and philosopher of information Luciano Floridi would point out, our image of the pipe is a sign or symbol, a token: in all, a proxy, of some specific thing that is to be made. It stands for the pipe, but doesn’t stand in for that thing. Our intention of the pipe can’t carry any fluid, only the intention of a fluid. Whilst Gilbert Simondon wrote of The Mode of Existence of Technical Objects, what we’re talking about here is the mode of existence of technical objects that aren’t yet.

Data upon data, information and product

My representation comes from a CAD model. This we’ll want to update and complete, then send to someone (another mind) who will have to interpret and act upon the data by, for example, starting to develop the bending process to convert what was implicitly a straight piece of tube into a correctly, intentionally, bent pipe. We’ll probably need to derive drawings from the 3D, and will certainly have make sure it’s been properly and sufficiently specified, with materials and tolerances and other quantifiables, before we can distribute the design data more widely.

As the informational load associated with this part begins to increase, its sub-components, features and functions begin coalescing for us into the idea of a product that could be delivered to a customer somewhere, ready to fit into their system. Specifications and requirements (themselves needing interpretation) preceding, following and accompanying our CAD models, will result in digital simulation and then physical test samples (which, although now physically present in the world still aren’t the “thing” that we sell), followed by validation reports (always returning to data); the design generates cost estimates and expected profit margins and contracts then, eventually, hopefully, an official release to enable our object to be made and sold at volume, profitably.

There are many layers of information through which we can view it, but sometimes, more often than we realise, we simply call it: the pipe.

Let’s return to the tool that helped me to produce that simple idea, CAD.

Assembled for duty

When we see a CAD model on screen, we can apply several different mental layers of interpretation to it. We can correlate it to the intended product, as I mentioned above, or to specifications, functions, costs and all sorts of other aspects.

We use CAD to define the basic geometry of a product, which matures as our models and intentions progress. What we see on screen also informs and affects our design, perhaps even our intentions themselves. But what is a CAD model, actually, especially that of an assembled product? As a colleague of mine pointed out recently, a CAD assembly isn’t really much more than a list of the parts and components that it contains, plus some positioning information.

A little more precisely, a CAD assembly is a list of the components that comprise it, plus the “news” of their positions and relations to each other, in the sense of what features of which part are connected to which features of which other part, and where they all sit in space. Combined, CAD and PLM programs enable the integration of a very rich set of additional information, like materials, coatings, positional tolerances, constraints and mechanical degrees of freedom, special characteristics, and so-on, plus the metadata of the assembly itself, such as its maturity state (in work, released, etc), revision levels, authors, contexts and - as always - so on, all related to this one object (and all other associated objects).

Part and partial

The interesting thing to me is that those parts used in the assemblies are, at heart, the same in nature as the assemblies. They are not much more than a list of sketches and features plus (the news of) their dimensions and relations to each other in the sense of what elements of which feature are related to which elements of which other feature, plus where they all sit in space.

Actually constructing those parts in 3D requires a trained mind, ingenuity and patience, and the ability to apply clever methods to achieve the goal of describing the intention of the product - which is why we often see companies employing specialist CAD designers to focus on that work, in the same way that engineers don’t always end up hammering the part into shape (or into the final product), unless they’re working at a startup, or on very early prototypes. CAD designers are a bit like the software developers of the mechanical world.

The combined skills of engineer and CAD designer result in the 3D representation of that part that indicates how it is intended to “be” in the future: again, that word, intention.

Even less real

Now we’re in this flow, we can consider those sketches and features themselves. Fundamentally, they are “nothing more than” code describing basic shapes and complex curves so that they are interpretable by our workstations, both for further logical operations and - in our human-engineer-centric fashion - for displaying the results on screen for us to interpret.

Perhaps that’s the crux of what we’re considering here. Within this hierarchy of data, reaching all the way down to digital bits, up to fully manipulable 3D models and all the way back down to synapses firing, we’re constructing mental images, generating and connecting information and knowledge that we need to be as robustly interpretable as possible, so that when we come to pass on these informational ensembles to others - people, organisations and machines - who will, ultimately, make, test, buy and use the “real-world instantiations” of those models, we will be able to finalise the development, have met an SOP (Start of Production) goal, and call the project a success.

Return to data

As complex systems become ever more simulateable and “senseable”, we are entering the realm of the digital twin, where data returns to data. The physical objects that are doing work in the world are one aspect of the value that we have achieved, but the data that they produce and return to the models is just as valuable.

It’s like the data that our apps produce to send back to the makers… well, for advertising purposes, mainly, but also, more helpfully, to understand how we use the app and to tune their work accordingly.

Eventually, perhaps even soon, even in my world of mechanical design, data will be managed by data to create new and better data, all within machine intelligences.

This is where the ethics of the thing arise: should we set a minimum level of human interaction to accompany artificial design intelligence (generative design, etc), or could we envisage black-boxes designing things for us and rating only the outputs? I guess that’s a topic for a future post (by my AI agent…)

Gamification

There’s an interesting offshoot to this line of thinking: a pipe for a computer game. There, the pipe never leaves the digital realm, but retains many of its intentions, including that of carrying some (no doubt toxic or lethal) digital fluid. However, since it stays digital, it doesn’t need any “entry visas” or any other passport documentation to enter a market in the real world.

The mere fact that it doesn’t enter the physical realm appears to mean that it needn’t carry as much information as a “real” thing.

Thingifying it²

Once our original pipe has been released into the market wild, the question still pertains: What is our pipe, in the end? Even that isn’t always clear. From our initial sketches and CAD models, whole manufacturing lines have sprung up to make pipes by the thousands each day: sales and forecasts are loaded into ERP systems, machines and tools get swapped in and out to make certain numbers of these pipes - or whatever it is we’ve been working on - quality tests and measurements are made and logged. Boxes and cartons, racks and dunnage have been designed and made available to ensure safe and efficient handling, and our products are now distributed widely, perhaps even globally, unobtrusively doing their thing.

Is one of those pipes, somewhere, our pipe? Are all of them, in sum, or is the whole apparatus behind them “our pipe”?

Or is, really, ceci our pipe?

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…

My previous post was about what I term a “field perspective” of work, which started out as a tangential idea on the engineering profession and our tools and was generally a happy, contented thing. When I encountered this heartfelt account from journalist Elle Hunt about her struggles with burnout a few days ago, I had to acknowledge it. She writes very openly about it:

The crash, when it inevitably came, was more of a hard stop. At around 11.30am my hands froze on the keyboard: I simply could not type another word. Trying to will myself on was a surprisingly physical sensation. I was pushing on a pedal that had got me this far – and finding, with mounting distress, that the tank was bone dry. Closing my laptop felt like a failure.

Burnout is a negative mode to the extreme within the spectrum of strive and thrive, stumble and fail, within those fields of perceived wants and needs that lead to plans and work, all within our own professional fields as well as the personal and the grand political fields. We are often left to manage these forces and strains by ourselves; sometimes the feeling that we’re unable to cope encroaches ever nearer.

Discussing the stresses of work is really important, even more so as the burnout wall approaches. The dilemma is that the closer we get to burnout, the harder it is to talk about it. Elle’s take on it is the right one:

I am sharing my story not because it is exceptional, but because I’m convinced it isn’t.

It was her introduction to the book that got me reading James Suzman’s Work, A History of How We Spend Our Time. Hopefully she can use the New Year to reset her relationship with work, whilst I keep firming up my own thoughts on Work: or what we do to ourselves as engineers.

A post from one of my previous personae, Literally Engineering, from November 2020. I keep coming back to this one, and feel that the overall idea stands up well.

A field perspective of work and politics

Why think about work?

I was going to write about applying engineering methods to philosophy (I still plan to). Trouble was, as I got further into it, that post became more and more unwieldy as considerations popped up like: what are tools? and: what are engineers? (Philosophy, eh?) Since engineers work (as in - it’s our profession) that’s how I came to start writing about work itself, to provide a basis for those questions that, I hope, will let themselves be written about a little more easily. 

Remember: this a blog post, so it’s not definitive and I’m sure to return to the idea once I’ve read more into it (I’ve also just started reading James Suzman’s Work: A history of how we spend our time) - but… here goes!

Work: what is it good for? 

Fulfilling, defining, meaningful consumer of time; a source of satisfaction, stress and sleepless nights, of distraction from the finer points of life, or of structured relief from the chaos of family and friends, all of whom can also be… hard work. That’s work.

Have you had that experience, that if you fixate on a word in your mind for too long, it suddenly sounds ridiculous? “Work” ends up sounding like a frog’s croak or something. But before it reaches that stage, “work” can stimulate all kinds of hints and notions and emotions, whether we focus on its meaning as a verb or as a noun, or let it flicker between the two. Professions, occupations, undertakings, jobs, roles, tasks, responsibilities, duties, even hobbies and maintaining relationships: all these forms of work are, fundamentally, as in physics, a question of energy transfer. 

Without a potential or a gradient, energy will not flow. And in the case of work, without a start signal, nothing will cause that potential to rise. That potential is of a mental, emotional nature that can, at a certain threshold, signal the pumps to start up so that energy can be transferred to whatever objective we have in mind.

The signal, the “programming” of the operation and the action itself involve the bridging of some gap between a current state and a future imagined state. All of that together builds “work”.

Building up the model (this is also work)

It is feasible, if unrealistic, to consider the future imagined state being precisely the same as the current state (the defining word here being “imagined”). Practically speaking, we might think of this as being the notion of maintenance activities, but maintenance is still “real” work, requiring energy. For this “zero work” scenario, we would have to imagine someone sitting in a pleasantly perfect state, with no improvement or activity imaginable. Or someone who was dead, but that path doesn’t appear to lead to any useful conclusions.

Here’s what it might look like:

This state can only last to the point at which our character becomes bored, or uncomfortable, or wet or cold, or hungry, or needs relief from previous digestive activities. A tension arises, which spans the current scenario and an imagined future state:

The tension of intention

Right now, that character can “see” and hold a new, imagined, state, in mind - a “field of intention” sounds about right as a name for this - but nothing happens yet beyond some highly complex neurological and physiological changes that prime our character for action. Mental maps are generated of where the action should take place and where appropriate utensils might be found, a general concept of how the action might be completed is mentally sketched, as is an assessment of how much energy might be expended during the undertaking - which can also lead to the conclusion: “ah, forget it”. It’s only when an action occurs, however, and physical energy is expended, that the tension can be resolved, as in the sketch below:

The arrow represents some kind of action, and the new state is now “real” - though it may or may not be the one that was imagined. Smashed cups, bleeding fingers or unsaved work being lost are not generally part of our imagined states, but they happen.

There might be complications…

Of course, in real life, things aren’t as simple as a single pairing of state and new state: there are near unimaginable possibilities for work and potential new states are bubbling up continuously and almost simultaneously in our minds - a major stress factor in life is often “what to work on?”:

Sometimes the answer is clear, sometimes not. Sometimes just doing nothing is… very appealing. Typically, it is rare that we can complete one task to the exclusion of all others. In the course of a day, for example, we’ll meander from task to task, completing some, making progress on others, ignoring others still.

Each point along the meandering path actually represents a new state, where new possibilities arise, leading in some cases maybe to the sudden elimination of one possible task, or perhaps the creation of several more. This results in the “bubble” of imagined states taking on a different form (or, at least, content), with different intensities, at any point in time.

It’s the intensity, felt or understood emotionally as well as rationally, arising from all of these potential futures and actions that drives our decision making

Constraints set us free

This is not the place to discuss in depth the notion of freedom, but it seems pretty clear to most of us in these pandemic times that freedom to act also requires ensuring the safety and security of others to act. This implies social constraints that allow us to act upon our fields with confidence (because we and those around us know what is right) or - if we have nefarious or illegal intentions - we have to have to act below or around constraints, in secret, for example. These constraints also condition the array of imaginable future states. 

This all brings us to the next point in this - up to now - very simple sketch: other people.

If operating in society is sociable, then even engineers are sociable

Fortunately for most, to the chagrin of others, we humans don’t live or operate in isolation. We live and work within groups that build fields of tensions. Sometimes those tension fields align, and are complementary, like “we’re all hungry”, or “our spears are rubbish, we need new ones”, or “we should invest in education for our children” … and actions based on those tensions arise, not all of which - it has to be said - are complementary or coordinated, but the overall vector of which can target the imagined state:

These groups may be small or large, and come from all ends of the spectrum of human activities. Some groups will be our employers. Other groups may be colleagues in other departments acting as further constraints (Finance! Sales! Purchasing! Legal!). Groups can be companies in competition within an industry, or from different fields mutually assisting one another (e.g. engineers and medics), or mutually opposing each other (environmental activists and fossil fuel energy companies).

As groups encounter other groups, societies build up, and the fields of tension become more complex still. Politics arises (also, by necessity, within our companies of employment), providing guidance and structure / infrastructure, as well as constraints - and gets messy:

Sometimes societies are largely peaceful and are able to maintain a way of life via consensus and legitimate state power: some permit autocrats or populists to come to power, who need to create and highlight enemies both from outside their society, and from within, usually distinguished by race or religion (sigh), who need to be subjugated or expunged:

Pictorial rant aside; In any case, ideas arise from groups or individuals and need recruitment of others to perform actions with sufficient strength to achieve those goals. Recruitment also requires coordination or coercion, but these are ways of guiding or moulding the “intention field” of others.

The future imagined state from here?

The future imagined state of this blog is to have posts on what are engineers, what are tools, how the two interact, and, ultimately, for this series at least, to return to the original idea of applying engineering methods to philosophy.

Thinking back to groups: can they completely bypass each other? Perhaps, but it seems that technology and the engineers who develop it are a link to pretty much all areas of activity in the “developed” world. Think birdwatchers without the creators of binoculars or monster telescopic camera lenses. And that’s where I think we can fit engineers into society - who will be the subject of my next post.

Stuff. Is that the best word I could come up with to start my philosophically tinged blog on the nature of engineering? Well, at present, it is. It’s the best. Up to now, I’ve been reading more than I have been writing, and in all honesty, “stuff” seems, as a word to use, more human, more engaging, simply more meaningful, than plenty of other words that I have encountered in my early reading into the philosophy of engineering.

Who’s talking about whom?

One fascinating subject that I have encountered, and one I am sure I’ll come back to quite often, is whether it is more valid for professional philosophers to philosophise about engineering than it is for professional engineers to “try” and philosophise about their own metier (which is, naturally, what I’m up to here). At present, in my current, extremely limited state of philosophical fluency, the vocabulary that philosophers use looks to me to be as technical, as opaque, as anything that I’ve encountered in engineering. It’s as if philosophers are talking to themselves about us: we’re the specimens in the lab and they are the all-knowing experts looking in and occasionally prodding. Looking back through the bars at what they have produced in writing (do philosophers have any other form of output?), I have the impression that if philosophers love one thing, it’s the exquisite agony of defining words exquisitely.

Those “omniscient experts” just seem to be talking to themselves. Therein lies the appeal of the word “stuff” to me right now: it’s maybe an overly familiar word, but it has the charm of being familiar, and carrying with it a rather vague set of meanings, so I’m not totally nailing somthing down too soon. I could equally assign a letter to represent the thing I’m referring to: F (we tend not to use S because of 5). Or, even better, something Greek: [\theta].

Back to the Stuff at hand

What I’m referring to with the word “Stuff” - or F - is the things that humanity makes. This means that F is a subset of “things”. Nature makes plenty of things without our intervention - but nature doesn’t make “stuff.” We do that, all by ourselves.

We don’t tend to give “Stuff” all that much thought, unless we’re going to be buying more of it and want to make a choice. An awful lot of Stuff is just there (indeed, an awful lot of Stuff is junk, or “tat” - but that’s something we’ll have to think about more deeply another time). Yet all of this stuff has been designed, developed (in various ways), made, and, increasingly, engineered. With all our concerns about energy consumption, efficiency and emissions these days, engineers have ethical questions to answer, along with the industries we serve: is cattle farming - or, more precisely, its outputs like cheese or beef, for example - “Stuff”, and can it be better engineered? But generally, most Stuff ends up as background noise to most people, like the fridge in the kitchen that you only notice when the compressor switches off.

It has become normal for us, even as engineers, to work on F or to use it without pausing to ponder the “what does it mean” of our endeavours. Others have done this in the past, and continue to do so now. These others are professionals, too: their job is thinking. That leads to another train of thought that stems from business: is a philosopher’s work an opportunity cost? Could they have been better put to use doing something other than “just” thinking, writing and publishing?

That’s something I’d also like to consider over the course of this blog.

The Languaging of Experience

I may have appeared to be a little scathing about philosophers’ use of words, but I also need to take care with my choice of words, and how they are packed into the text that I’m hoping to use to transmit my thoughts or experiences to you. So, I will be as careful as I can be - and gladly accept any criticism of vagueness or confusion generated through my choices. If I were to be grammatically correct about it, the title of this post should be “Here is Stuff”, taking “Stuff” as a singular word denoting the plural - but because “Here Be…” just sounds better, more piratey, than “Here Is”, that’s how I’ll take it for now. Arr.

What am I doing, again?

I’ll do lots of reading. I’ll list out the reading I’ve done, and estimate how much I have understood what I read. I’ll write posts on thoughts that arise from that reading, as well as from my own engineering experiences under this new perspective; posts on various topics and concepts that I stumble across during these hobbyish endeavours. Perhaps something will form out of it: an idea, a concept that might help me, possibly even a reader, to understand a little more the “why” of what we, as engineers, do.

This is all at the risk that it might all have been my very own opportunity cost, too; I should have been practicing the trombone instead.

Sorry.

(especially to the design and process engineers who designed, developed and made my particular trombone, to the engineers who designed and validated the materials in roads and ships, to the developers of the logistics systems, of the barcode readers and truck tyres that, together, managed to get my trombone to me. To the printers of music, the extruders of aluminium music stand components - and to the makers of earplugs.)

Learning a new language

On the face of it, there shouldn’t be a significant difference in how we approach a new topic in engineering or in philosophy. There is always a new vocabulary to learn, new correlations to be made between concepts, and new ideas to test out, to confirm, modify or to reject.

On the face of things, there is a huge difference between how an engineer approaches a new topic in engineering and in philosophy. In engineering you can build and test things, trial responses to inputs, generate outputs and visualisations of your data - and break things. In philosophy, that looks to be… challenging.

If I use this word instead of that, what is the difference in output, in philosophy? Right now, if you’re like me, it’s constant: “huh?” Ontology? Ontogenesis? Epistemology? Individuation? They mean next to nothing. It’s next to impossible to create a test for the difference between ontology and ontogenesis because we don’t understand how to clamp the words to “stress test” them. What is the Young’s Modulus of ontology or of ontogenesis?

Looking at it from another perspective; if I were to write a software programme in the language of philosophy, it would be riddled with syntax errors and unclosed loops.

But therein lies the appeal: philosophy birthed the world of logic, meaning [watch out: is this next clause testable, verifiable?] - meaning that logic is contained within philosophy, so logic’s rules apply.

But, I’m entering a new world, which is a bit like starting a new job: I’m meeting the people, learning their terminology. I don’t want to be too rude or disrespectful; I’ll ask questions, carefully enquire as to why they do things one way and not another - and soon perhaps I’ll be in a position to start designing tests and experiments to see what all of this means.

with this post from 2019, four years after my previous and final post as Literally Engineering, I started my journey into the philosophy of and around engineering. Posts became more infrequent, but I’m glad I made the switch, since the philosophical perspective(s) has enriched my career

What has philosophy got to do with engineering?

Philosophy and engineering: oil and water. They can sit in parallel to each other, never really interacting:

Depending on your perspective, the layers might be the other way around: philosophy “supporting” engineering:

Of course, Philosophy could be viewed as being the basis for everything. Without philosophy we wouldn’t have created mathematics, logic… (just putting this perspective out there!)

Now, if someone is willing to add some energy into the system, and some additional mixing agents, like ideas, then stir things up, we can create an emulsion:

Some emulsions are stupendously useful (like paint), others… less so.

I’m guessing that an engineering-philosophy emulsion will end up on the not-so-useful end of the scale, but for some not really fathomable reason, I’m willing to try. But why…? That’s something I’ll try to answer with this blog.

There’s the old adage (with a million variations) that an engineer needs a philosopher like a bird needs an aerodynamicist. The bird will fly regardless - but perhaps we, if not the bird, can learn something along the way.

another attempt at a (knowingly!) overblown “literary” telling of a small event from 2015

The planet cast a long, dark shadow into the stream of light from the system’s star: it was in this occlusion that he travelled, his face lit only by the dim glow of information panels as he sat in warm isolation, snug in the metal and fabric embrace of his cabin. Others were travelling on similar trajectories: this was a well-used if minor conduit between two minor habitations. Interaction was not desired by any traveller, each ensconced in their own, almost foetal, form of high-speed tranquility.

With a silent boom! a photon energy beam burst around him: the surrounding vegetation appeared as a clear, deathly grey-white ghost of itself. He knew: the Blindness was upon him. Then - puzzlement rather than dazzlement: he could still see. His retinas were not seared, the cockpit around him was not melting into an unbearable reaction chamber of light followed by unfathomable patterns on his visual cortex and new depths of darkness. Instead - he was comfortable, and confused.

He checked his rear-view optical sensors, and saw: dim lights. Their coruscating beams danced and glanced in the trees around him, but kept their most piercing lances shielded from his eyes.

Then he recognised the signature shape and form of those lights: they came from a BMW - and could only have been their adaptive LED headlamp system.

He smiled to himself. Our species is just so inventive, he realised, and just doesn’t know when to stop tinkering, even with the most traditional of technologies. Headlights today, interplanetary mood lighting tomorrow, each component and subsystem being developed by whirling and evolving teams of scientists, engineers, manufacturers and - yes - sales people and buyers. Cultural systems enmeshing imperfectly with imperfect electromechanical systems - causing clashes and jolts aplenty - leading to the evolution of the normal. He was glad to be part of it.

posted in 2015, this text was I think an attempt at capturing the solitude and darker thoughts of a sleepless business traveller - and, boy, did I sleep poorly on most business trips (mostly, I now realise, to my FODMAP intolerance to onions and garlic. I clearly wasn’t on a business trip on the 27th of December, but remembering one - probably brought to mind by a similar poor night following a celebratory meal

Disorientated. Where? Dim pre-dawn - or streetlamp - light crept lethargically, reluctantly, unenergetically through a gap between blackout curtains. Energy aplenty thundered in audio form through the window and into the room: sound waves, but not homely. A hotel room. A truck, or a tractor. Almost military. No, not that - but east European. One east European truck or tractor followed by another: agricultural. A church or town hall bell, three simple rings. What in God’s time is it? Yes, three quarters past - quarter to - what?

Where, a hotel room in Romania. When, a quarter to. Who? And why?

Hand stopped half way to reaching smartphone and dropped back onto the bed. Time was unimportant now, as was place. This was him: a family man. This was him: a company man. This was him: an engineer. Half awake, three quarters not there.

So - a company man. Could that be a defining characteristic? If so, then he had changed. If not himself, then at least his company. He didn’t feel that different after all, even if he was now working for the competition. So - not defining. It was a new start, let that be sufficient for now (not this short now - a long now). Fresh perspectives and new beginnings had brought fresh motivation and impetus - surely to fade - but why not enjoy making new connections and revisiting old challenges with fresh eyes?

A company engineer and a family man: plenty of work to be getting on with. Reason enough not to be lying unasleep in a foreign bed, awaiting meetings, reviews, discussions, coffees and presentations with a whole new group of people. For what? Oh, don’t let’s go there now: there is no what for. Especially when the real question is: for whom?

I am why. They are why. You are why I read specifications line by line - especially the ones I have written; why I go through drawings item by item, FMEAs cause by cause, assign component attributes like a librarian, consider new developments like a patent lawyer; test parts, write reports, write emails, write presentations, travel to stranger places than this - and, from time to time, to write about it all here. For the company: your company.

Four more simple rings, followed by four sonorous ones. Two and a half hours to wait for the smartphone to ring, hopefully until then oblivious to time…

I’m writing this between lectures and dinner on the first of a 2-day FMEA forum in Osnabrück and I’m trying to figure out what to make of it all. If that opening sentence fails to give the impression that I’m bubbling with enthusiasm or energy from the day, it’s because - well, I’m not. Of course, sitting around being talked at isn’t the most energising of inactivities itself, but the content shown so far hasn’t fired me up in any significant way.

The theme of the forum is “FMEA success stories” - but those stories have been in fact pretty sparse thus far. Two of today’s main presentations were about their respective companies' efforts and struggles to implement strong FMEA systems and culture into their workflows. One company gave an update on its mission (now into its fifth year of ‘x: unknown’) to implement an FMEA software system and methodology into the group. The other gave a shorter overview of how they’re getting on (or not) as they make a start on the challenge. The takeaway from these presentations was the obvious: yes, it’s difficult to move away from scattered, ineffective but audit-tick-boxable Excel files to a centralised monolith. And, yes, you need executive and management support for such an undertaking. But not even from the company that is so far along the road did I hear a story about benefits. They have basically arrived, but where, and why? I didn’t hear any anecdotes about finding otherwise hidden potential failures, about reducing potential quality issues by humungous amounts, anything like that

One presenter plucked up the courage to show his efforts to convince a director to invest in FMEA via the means of monetary value (another key theme of this forum). Our presenter’s take was that robust and reusable FMEAs help to prevent project overruns - (on the basis that you won’t be validating things too late, and when validated, then with the expectation of OK results), so the most convincing financial metric was in fact time - a shaky assumption if ever there was one, and one that nobody could pluck up the heartlessness to destroy in the Q&A afterwards.

There is a close-knit group of FMEA gurus in Germany, who attend each and every one of these forums. They consult for others, and many of their clients were here, too - so there is certainly a self-appreciative air to the proceedings, of their being a natural and self-explanatory part of the engineering world. Data is less available. But one guru at least mentioned that his research team studied around 500 FMEAs before and after switching to more robust software and methods: the robuster methods rooted out around 30% more potential failure causes than the older versions. He did proceed to weaken his argument somewhat by stating that most of these were repeat or piffling items, and there was no factoring of the “novelty” problem (would these new causes have been arrived at had the systems been analysed with fresh eyes, albeit using older methodologies?) but at least a couple of the new ones could be treated as being noteworthy.

So - these success stories we’re talking about. They are where, exactly?

There was a presentation on making FMEA meetings more effective by trying to eliminate discussions on rating causes (occurrence and detection ratings), and by highlighting the financial aspect of potential risk - but that’s still a very inward-looking process improvement.

A further presentation from two “big” Americans (in the sense of being FMEA-gurus from America) tried to show the differences between the AIAG and the VDA-described methodologies - but that was a thoroughly overblown observation. When I asked if anyone had “raced” AIAG against VDA on the basis of one common design, to test the theory, or even to try and see if one method favoured one type of result over another, the answer I received was an at least nicely succinct “no.”

That discussion all boiled down to “it doesn’t matter which method you use, as long as you use it properly.”

To turn the focus back on success in FMEAs: how can it be measured? Of course, it’s the nature of the FMEA that potential failures are thought up, thought out and minimised - and those thoughts involve (or should involve) a lot of internal company knowledge and evidence. So nobody wants to (or is permitted to) talk about specifics - but with the forum having been so entitled, I’d have thought that the organisers would have found a way to try to tell the stories in a stronger way.

Perhaps, though, in the context of such a forum, they felt they were preaching to the converted, anyway, so didn’t need to do much “selling”.

Click ‘Go’ to start

Generally what an FMEA is trying to do with a mechanical system is to bug-check its logic. Perhaps we could consider a better tool from software development (How Google Tests Software, for example), where a model is created that through a multitude of test runs can quickly highlight the potential week points. That would be even more difficult than manually thinking things through - but cleverer. Perhaps that’s simply where we stand right now: we’re chipping away with post stone-age but pre-steam tools - and doing a pretty decent job of it, we think.

I know, let’s look in the FMEA

A common selling point of the FMEA is its potential (that word again!) to capture a company’s knowledge through lessons learned, updates and actions, linking to evidence and reports, etc. I was also sold on that for a while, but right now I’m less confident about it. After the “5 year-mission to explore new worlds” presentation, I asked how many of that company’s development engineers use the FMEA software. The answer was: none. Of course expert systems can be difficult to drive, but it seems strange to me to have to rely on external moderators to create the FMEAs, and then on searching through pdf documents to find key lessons learned and design considerations.

Where does FMEA belong?

Many of the FMEA colleagues I met so far came from Quality Management - which I feel should be the parking spot for completed FMEAs. But FMEAs that are still themselves under development (theoretically in parallel with the ahem new product that is gestating) should reside with the product- or process-development teams.

I raised this point later over beers and dinner: others countered that engineering students don’t learn about FMEAs in any meaningful way, so they can’t be expected to maintain one as part of their jobs in the same way that quality engineers do: but that’s more of a comment on engineering education than on any philosophical decision to shield development engineers from such shudderingly plodding work as FMEAs (to put a negative twist on it).

Go on, have another beer and lighten up

The key to these FMEA forums is, of course, the networking. Everybody in the field, regardless of product, industry or division (quality or development) has basically the same problems with FMEAs. But few really try to come to terms with what it means, and what benefits the system has. So it was good to meet a few skeptics among the herd who saw the presentations as well-meaning but non-value-add guff, and who also saw the principal value of such forums in the people themselves.

The evening dinner of local Grünkohl and Pinkel sausages in a local Osnabrück brewery (Rampendahl) made for fascinating conversation, especially as I ended up sitting amongst three of the world’s key FMEA software developers.

But now, after some noticeable time-hopping, it’s time to upload this post, grab some breakfast, and get ready for the onslaught of the second day…

It is fair – and not in the slightest bit unusual – to say that we have been struggling to apply our resources properly of late.  My office is nominally dedicated to product development - but, with our well-appointed laboratories on site and our general level of expertise and “seen it all” experience, we’ve ended up having a whole pile of test and validation work to plough through, which, as I’ve pointed out in the past, I personally don’t view as one of this engineering life’s great driving forces.

{An aside: ensuring that your development team is focussing on its job is a perennial battle: a recent article in the Economist on the future of work points out a study done by Pfizer in 2008 which showed that its most highly skilled employees were spending around 20 - 40% of their time on routine work. Now, if I could even get up to 20% development work, I’d be happy…}

Roll up! Roll up! Become a validation engineer!

So - I want to be less involved in validation. This means I need somebody else to do it for me. I’m not a marketing type by any means, so enthusing about something that I despise doesn’t come naturally - but I still need to think through how to “sell” validation to someone else. I need to think things through, which is the general point of a blog, unless I’m very much mistaken - so here goes:

• There are plenty of people who like little more than running around organising things - defining who needs to send what to whom and by when, then chasing up on all those leads.
• There are others who have the ability to create, track, update and check off tasks in lists.
• There are still others who enjoy the mechanical challenge of getting parts to fit into unnatural environments (we don’t necessarily design parts to fit into test chambers)
• There are plenty of people who feel important when they get to put a “pass” or “fail” stamp on things.
• There are engineers who can lose themselves in reading and understanding specifications,
• And there are those who are happiest with the prospect of endless work without much in the line of variation.

A validation engineer needs to combine all of those attributes.

That’s me in the mirror

So which of these attributes don’t I have? Well - to point out the obvious first: I can work on validation (successfully, too, it would appear, as I keep on getting more of it to do!) - I’ve done it for year upon grinding year. I fail dismally at routine and at repetition (validation often requires testing the same set of combinations over and over, from different production locations or tooling sets, for example) and I really have to force myself into ordering precise numbers of components, counterparts, etc, force myself into counting the parts that arrived, and figuring out how to fit them into test equipment.

But it’s largely a condition that borders on the philosophical - validation is at the wrong end of the engineering spectrum for me: it should be the crowning “dumb” step at the end of all the concept, specification, definition, understanding and testing work that constitute the development of a product into something produceable in series. It is validation as in rubber-stamping: this is a valid product; it does what it was expected to do, namely – meet specifications.

Meeting specification is the go gate for product in the “physical” world – not release into the market. We can’t iterate as quickly as app writers can, but also smartphone apps don’t generally have the potential to kill people if they go awry. So the biggest task for an engineer in the traditional industries is to write a cogent, coherent, consistent – and legible – specification that can act as a realistic hurdle and as a decider between good and not good product.

Then, other engineers need to read those specifications. Alas, the percentage of humans who have actually read through, understood and organised test work according to specifications is as vanishingly small as the number of people who actually wrote those specifications still being in that role.

Let’s validate - something - quickly!

As soon as someone, somehow (often based on arcane and mysterious procedures – or company lore – or on a whim) decides that validation testing is required other than as the natural end of a development programme, chaos ensues.

Emails are sent expressing urgency, whilst tacitly acknowledging cluelessness regarding how actually to proceed; priorities are dumped on the already overloaded yet ever-helpful testing team – and above all, the sense of the emails is one of desperate hope. Hope that responsibility can be abdicated, that no further questions will be asked, that no sample parts need to be organised, that timing will be according to promises already made.

Of course validation is urgent, and of course it’s important – in our world you’re simply not permitted to deliver (or be paid for) parts that have not satisfactorily completed validation. It’s just that, for a development engineer, validation (as opposed to development testing) is dull, dull, dull.

There, I said it.

Finally, though, we managed to get some outside help, and we hired a student – more about which in the next post…

More than a few years ago, bordering on the “many”, I was invited to take part in a graduate selection weekend for Ford in the UK. It was a battery of tests ranging from one-on-one interviews and team-working simulations to presentations and problem-solving “incidents” – all nicely wrapped up in dinners and coffees in a pleasant hotel in the countryside.

One of the tasks – maybe there were twelve of them, I didn’t count – was to decide what equipment should be offered as optional, standard or not at all for a sporty Ford Escort model (these were the pre-Focus days), to meet a budget. We then had to write a report explaining our choices, needing to meet a most important deadline (lunch).

Being a bit of a car enthusiast, I made what I thought was a decent selection (including ABS and airbags as standard equipment), whilst keeping some budget for a few luxuries as standard (a CD player, I think), to differentiate Ford from, say, BMW, whose cassette tape decks were one optional extra, speakers to hear music from seemingly another…

Being a well-drilled undergraduate engineer, I wrote the subsequent report in the only way I knew how - with an introduction, a summary, a body and conclusions.

When I was given the job offer a few weeks later (which I took - a decision point that remains with me to this day, and is definitely worthy of a post of its own), Ford gave me some feedback over the phone. My presentation had been borderline terrible, but the report I had written was excellent.

In fact, it turned out that I had been the only candidate to actually write a report. Everybody else had written prose.

So, in honour of that, and in recognition of the possible fact that report writing remains for me, over emails and presentations, the main recipient of work related keystrokes, here’s my report on report writing in engineering.

TITLE

An Investigation into the enduring and endearing constraints of report writing

Author

The Literal Engineer

SUMMARY

The act of reading a technical report involves a certain mental effort. This effort should be rewarded with increased knowledge. In order to minimise the effort and to maximise the potential for knowledge extraction, the report writer should generate the report in as standard a way as possible.

The act of writing a report invokes a particular and peculiar mode of language, which itself requires a mental switch and effort to maintain, the passive voice. Writing in the passive voice lends the report an appearance (but no guarantee) of objectivity. A potential pitfall of the passive voice is the risk of the writing becoming stilted and unreadable. Yet this pitfall is deemed to present a lower risk to knowledge transfer than chatty and poorly applied novelistic writing.

Deciding on the tense remains difficult. The report should be written with history and evidence in mind; a report is a snapshot of the status of whatever is being investigated at the time, in this case – report writing. Using the passive voice is, overall, a positive constraint.

EQUIPMENT

Mid 2012 MacBook Air

2006 Rain Recording PC workstation with Logitech keyboard and mouse

Microsoft Word 2013 and Online

Microsoft Office 365 / OneDrive

Typepad blogging platform

Evernote note taking platform

Firefox and Safari browsers

1. INTRODUCTION

A technical engineering report can be understood as a window to a complex and meaningful event (or series of events) that took place within an organisation. The intended goal of a report is that its findings be understood. For this goal of understanding to be even remotely achievable, the report writer must describe the event in sufficient detail with sufficient brevity and clarity to form a synthesis of the outcomes of that undertaking. A report should therefore be  logically structured and legible.

Ideally, the summary and conclusions from a report should add to the great body of human knowledge. It is recognised, however, that, more often than not, reports must be produced to describe small-scale and often painfully regular events.

Regardless of where a report lands on the scale of import (or lack thereof) to humanity, the form and language follow traditional structures. Report writing in the technical fields is designed to enforce (the impression of) objectivity. The passive voice depersonalises the investigation and can be construed as an attempt to prioritise facts over individual actions.

I did not post this report on 30th Sep.2014

rather:

This report was posted on 30.09.2014

The tradition of using the passive voice imposes a constraint on the writer, which forces upon him or her (the passive voice at the very least enables authors to avoid the awkward distinction of the sexes) a mental switch and effort to make and to sustain the passive voice. This is an appropriate cost of entry, as the reader needs only recognise one style, whatever the source of the report.

2. THE STRUCTURE OF A REPORT

Reports are constructed around a common set of elements that may vary in style, format or order from organisation to organisation, but nevertheless ensure swift navigation to the pertinent sections or level of detail for the experienced reader - from an overall summary (usually to be found near the beginning), to detailed descriptions of equipment and methods used, via a logically structured body of evidence and discussion. The report at hand loosely follows such a typical structure and does not purport to set any standards with its own form.

It is also based on very little evidence.

3. THE CONSTRAINTS IMPOSED ON LANGUAGE IN REPORT WRITING

Actions and analyses leading to conclusions and summaries – no matter how breathlessly exciting at the time of their experiencing – are, in translation into a report, passed through a mental filter that compresses them into the passive voice.

This imposes a constraint on the author, which, similarly to the imposition of a recognisable structure on a report, lightens the burden on the reader (see Section 3.1 for more considerations on the reader’s role).

As in so many cases, especially in the arts and in engineering, this constraint can be viewed as overall positive: few physicists or engineers have been recognised as possessing the gifts of novelistic writing (or even spelling); honing the craft of the passive voice relieves these authors of many grammatical pitfalls.

The key to the passive voice, and the difference to novelistic writing, is that there are no characters or personalities to deal with. Someone or something does not do something to some other thing or person. Rather, some action is done to some object.

The strut was loaded into a tensile testing machine and its stress-strain curve was determined.

The sample was subjected to 60 cycles of cyclic corrosion testing according to specification X

The tea bag was placed into the pre-warmed cup. The cup containing the tea bag was filled to just off brim-full with boiling water. The assembly was left to stew for 4 minutes.

Humans act in all technical investigations, but the passive voice strips them out as being extraneous information. Whilst this is not always to be considered positive in most human relationships, being able to divide out the common denominators is, just as in arithmetic and mathematics, key to understanding the basic signals of what is being investigated. Humans, then, are a form of noise – in technical reports, at least.

Writing in the passive voice is a skill that must be honed with practice. For as long as the passive voice does not come naturally to the author, each sentence needs to be reviewed to ensure that the reader is not forced to stumble upon a person or a character rather than a description.

The implication of objectivity is valid. It doesn’t matter who did the test (especially in the sense of Professor vs. technician, or he vs. she): it’s not a diary. That information can be captured in lab notes, engineers’ notebooks, or the famous case notes from AT&T Bell.

3.1 THE BENEFITS OF THE PASSIVE VOICE

The passive voice is intended to portray the investigation as being impartial. This:

• enforces a certain mental discipline
• requires a certain mental “Umstellung” that brings the author into a standardised frame of mind.
• permits the reader to read reports from any source in a similar frame of mind.
• avoids “War and Peace”-style questioning of who was doing what to what other thing – no need to buffer names
• ensures that personalities and their status are largely avoided
  • The facts and conclusions come first.

3.2 DISADVANTAGES OF THE PASSIVE VOICE

• It is easy to “hide” the contribution of laboratory personnel, lower level engineers, and so on, to attribute the report to one “star” player. This is more likely to be an issue in the world of university, where academics are forced to publish on a regular basis – a quality investigation on a returned part is less likely to be the cause of professional envy.
• Can be stilted, can become impenetrable,
• Enforces the use of some awkward words or constructions

4. SELECTING THE TENSE

A key decision that needs to be made early on in writing the report, one which generates some confusion, even within one report, is the tense. Some decision aids are suggested as follows:

• Tests are described in the past tense: they were performed (“the samples were tested using the tensile testing machine at yy mm / minute”)
• Results are described in the past tense: “the stress-strain curve Fig. x.y was generated”
• Findings may be either in the past or in the present tense:
• If a test was performed on a particular sample, e.g. investigating a failure, then the findings may be presented in the past tense:
  • “brazing of the joint was found to be incomplete”
• If a result was fundamental, then the findings may be presented in the present tense: “the maximum tensile strength of the xx joint is YY MPa”

5. CONCLUSIONS

The technical report remains its own art form. Its art is knowledge and its form shall minimise the resistance to knowledge transfer. I really think that the passive voice helps to – oh, damn!

BIBLIOGRAPHY

www.sussex.ac.uk/ei/intern…

Whilst I’m no longer much of a gamer (I finished Half-Life 2 and got several hours into Oblivion before dialling down the game time), I do like to keep tabs on what’s going on in that world. Right now, the biggest thing since sliced zombies is Destiny,with its massively online save-the-solar-system campaign of dealing death to death-dealing aliens. Its creation was a huge undertaking, both in terms of manpower and financially.

One paragraph of one article about Destiny really stuck with me, though, and it didn’t have much to do with the game itself. The Guardian newspaper (I wonder if they got additional access because of the paper’s name?)  had a behind-the-scenes article about Destiny that described how large an undertaking it was. The project was so big and so complex, with so many people working from so many different perspectives in such a big converted cinema, that they created the position of “workflow engineer”:

“The company employs a workflow engineer, Brandi House, whose job it is to mediate between the art team and the programmers. “The team kept growing so it became harder to just walk up to the engineers' desk and tell them it’s not working,” she explains. “The engineers started to say, ‘Well, we have 200 artists – I can’t get any work done!'” House has a PhD in electrical engineering and is an expert in user interfaces – now she’s applying that skill with systems to a workforce, - she is effectively debugging the development team.”

This is the wonderful thing about engineering. It is so loosely defined that it can seemingly be applied as a concept to pretty much anything. For engineering to really kick in, that something needs to be complex (yes, a pencil is complex, if you look at it from the right perspective), it needs to be definable and there need to be adjustable parameters so that an optimum can be targeted.

Once you know more or less how something is, you can define - more or less - how it could, or should be, and how - more or less, once again - to get there.

So, whether it’s sorting out your early morning breakfast workflow, or designing your low orbit home rocket - or even if you’re nominally an engineer at work and want things to be better: engineer your destiny!

Note from the future (2024): another attempt at linkblogging. There’s some humour here, but it’s a bit silly

I just love the headline from the first newspaper clipping in this BBC News article: “Engineer hits out at ‘embarrassing’ India”.

Alas, it turns out that the Engineer in question was Farokh Engineer, who kept wicket for India in the 1960s and 70s…

Still, it’s nice to imagine subcontinental sports writers deferring to the clearly superior insights of the engineering profession.

Even I recognised that India were rubbish in the last few Tests in England.

Note from the future (2024): I guess I was trying out linkblogging here, but it doesn’t look like my heart was really in it.

Flamewars in SPAAACE: cooler fires hint at energy efficiency • The Register This looks like a really interesting lead in developing more efficient combustion: burning cooler, for longer, seems to result in both improved efficiency and reduced emissions.

We only need to generate microgravity combustion chambers, and we’ll be away!

Jon Gertner’s The Idea Factory: Bell Labs and the Great Age of American Innovation is tech reverie, business book, political thriller and a superbly researched history into how some of mankind’s most profound technical innovations (semiconductors and the transistor, solar panels, lasers, communications satellites, cellular mobile and Unix…) developed from fundamental ideas into production and into normality.

It is an exhilarating and – to this engineer, at least – humbling read with an appealingly comfortable feel to it of the book almost having written itself.

A history of people, biography of a formula

The narrative follows the giants of Bell Labs from their induction into AT&T to their passing: insightful Claude Shannon and incisive William Shockley, the genial instigator John Pierce, the politically adept scientist Bill Baker and a cast of thousands working within the innovative innovation structure constructed by the angular visionary Mervin Kelly.

Kelly’s formula is the leitmotif running alongside those histories. Both culturally and architecturally, it was about ensuring happenstance. Scientists were meant to be unable to avoid engineers, chemists were meant to bump into physicists and the men who “wrote the book” to interact with those who “read it.” It was a theory of ivory corridors and canteens rather than towers.

Hearteningly for small-fry like me, those who shared lunch, labs and projects with the Giants are also called out by Gertner for their contributions as lab technicians, metallurgists, engineers, project managers, chemists or physicists. There is always that sense of perspective that the products initiated by the Shockleys and Shannons of the Bell Labs world really needed input from each and every member to take them to production.

He didn’t mention the cooks, though.

The invisible enthusiast

Jon Gertner is a journalist who has written for the New York Times and – less promisingly, perhaps – is editor-at-large at Fast Company*. This is his first book, up to now his largest undertaking by far. He spent five years building up this story - and it doesn’t show.

Not once did I feel the weight of his research, nor the burden of history, whilst reading The Idea Factory: the research and painstaking editing behind it is transparent. Gertner writes precisely yet lively, reflecting perhaps both the industrial-academic environment he describes and the local aspect of his endeavour: he grew up near the slightly mysterious, legendary Bell Labs headquarters at Murray Hill and his need to write this story comes across as being personal. Thankfully he found the energy and made the time to write it.

A monolith of innovation

AT&T enjoyed and, in pushing the boundaries of legislation, abused its monopoly position to maintain its role as “The System”. Those researchers and developers thrived within a massively integrated firm with the manufacturing might of Western Electric (which lovingly crushed or bought up many competitors in the past), the financial momentum of the phone operator (equally crushing), and the laboratories that drove the organisation to higher margins as well as higher callings (in not just the telephone sense…)

The calling to innovation as a justification of monopoly is the fascinating twist on our perception of this otherwise shimmering paragon of development. Teams that innovate need to get grubby, they need to ensure they have the best people and should “Never underestimate the importance of money.”

Without mass production, sales and distribution, no product may be considered to be innovative – so all of those tedious tasks surround, and can occasionally swamp, a product as it moves onwards to the market.

Notational Philosophy

The story behind the invention and development of the transistor would be worth the price of entry all by itself. But Gertner embellishes it with such lovely, pertinent little details that the reader can find thoughts spinning off in unexpected directions. One gem is the rigorously maintained notebooks used at Bell Labs. Each team member was required to write down thoughts and events relating to a particular case (or project, as we would call them now). Walter Brattain’s notebook, number 18194, relating to his work on semiconductors (case 38139) continued on page 40, after 4 years of interruption through the Second World War, with: “The war is over.”

There are other notational quotes in the book: from Morry Tanenbaum, as he closed in on discovering how best to manufacture layers of p-type and n-type silicone for the transistor: “will try direct approach…” (he melted an aluminium wire through the top layer) “This looks like the transistor we’ve been waiting for.”

These notebooks are - handwriting permitting - legible now, and are exceedingly well archived and organised. Will we be able to say the same of our loosely-managed files and cloudy projects in another sixty years? On the other hand – how searchable are those notebooks? Who can extract the knowledge that they contain, as well as the narrative, without knowing them intimately?

John Pierce – my new role model?

Although less well known (to me, at least) than the “transistor guys”, I felt an immediate affinity to one character that was totally new to me, John Pierce, of Telstar Satellite fame. “An instigator is different from a genius, but just as uncommon,” writes Gertner. “It was probably accurate to say that Pierce had too many ideas to actually pursue on his own, and too many interests… to focus on any single pursuit.”

Ah, I know this feeling only too well.

“’I tried to get other people to do things, I’m lazy,’ Pierce once told an interviewer. ‘Do you think this has helped your career?’ the interviewer asked. ‘Well, it was my career,’ Pierce replied.”

Pierce was a catalyst within Kelly’s formula of deliberate entanglement – wandering into offices with a bit of an idea and “just” starting things. It’s something that really should be encouraged, and perhaps remodelled in the virtual world, given how few offices are actually connected back in the real, normal world.

Moving on (looking wistfully back)

The book ends naturally with the passing of the golden generation and the fading into normality that is more poignant than any dramatic burn-out and crash. Gertner offers his thoughts on the meaning and lessons to be extracted for today’s Googles and Microsofts, for the myriad of startups gunning for their lunch – and for mere mortals like me.

Firstly, he considers whether swapping a factory of ideas (Bell Labs) for a geography of ideas (e.g. Silicon Valley) can match the muscle provided by monopoly. It’s close, perhaps, but, for all the advances that Silicon Valley has given us, in comparison with Bell Lab’s output, it has been largely incremental.

Secondly, he wonders if there is a way of escaping monopoly and government involvement in basic research at all. Here, he points out that “77 of the 88 U. S. entities that produced significant innovations were beneficiaries of federal funding.”

The concept of government involvement in anything brings with it the perception of incompetence, but Gertner summarises research into research with this:

“Creative environments that foster a rich exchange of ideas are far more important in eliciting important new insights than are the forces of competition."

White shirts and ties - the key to innovation?

Amidst all the deeply scientific and creative thinking going on at Bell labs during the “wonder years”, one constant appears to have underscored the whole process – everybody wore white shirts, and ties. Some eccentrics were known to go sockless in their shoes, but the fundamental aspect of Bell labs appears to have been the shirts.

My wardrobe consists of perhaps three white shirts, one of which is my wing-collar concert shirt for orchestra: it hardly brimming with scientific rigour.

So, when knocking on other peoples’ doors we should clearly be wearing crisp white shirts.

Hmm… a hint of sartorial determinism there? Perhaps Kelly has a better take on innovation:

“It’s the interaction between fundamental science and applied science, and the interface between many disciplines, that creates new ideas…”

This book is simply worth reading, and is worth reading again. So once you’ve got it, read it and lent it out, make sure you get it back…! 

*(5 amazing lists on the habits of 8 of the most productive ’10 of’ list writers in business today, to click you cleverer” could be a typical Fast Company headline, even if that’s only four lists)

Note from the future: this was me rebranding from On Engineering to Literally Engineering. It was fine, but I’m glad I didn’t pursue this direction for too long

An engineer who knows the difference between literally and figuratively? Very suspicious indeed! Yet here I am, proudly rebranding myself as an engineer who also deals in words (and sounds, but that’s another project). I’ve always needed to write, just as I’ve needed to nourish the technical aspect of my brain. When I’m at work, I’m, like literally engineering. At home and here in this blog I can be literally minded - thinking, reflecting and, from time to time, writing about engineering.

It’s a big topic covering an unimaginable range of products, from things that we touch and use every day - to the arcane, that we rarely, if ever, see. And yet it’s a small, parochial topic, too. Specifications, drawings, tolerances, materials - all of these need nurturing by us, the oft-unsung engineers, wherever and on whatever we work. And to do that, we need, like it or not, literally to use words.

So, here’s my fresh start, with a fresh suit - which will need some nipping and tucking as time and wear go on. Let’s see where the journey takes us…

We had a customer review today on one of my favourite topics in the whole wide engineering world - validation. Even though mentally I was gritting my teeth whilst they were being figuratively pulled, line item for line item, I think I managed to keep my friendly face on for most of the discussions. In fact, at a personal level, at least, the customer and I got on fine - and that’s most of the battle won in any aspect of business.

The ability to chat around as well as “deep dive into” the test plan helped us to skirt the realm of the kafkaesque; boxes still need ticking, and the time bomb of deadlines remains, but we could represent, or “play” our roles amicably. We touched upon the (lack of) sense of most validation testing in the automotive world and how basically inane the whole thing is, in reality, whilst accepting the fates that specifications and their authors bestowed upon us.

He wanted to see some testing in action, which is fair - it’s his product, after all, and his specs we’re testing to, so we visited the labs to see how things were going. The technician happened to be performing a vacuum seal test at the time: pull the vacuum, wait for it to stabilise, close off the valve, let the test sample stabilise, start the clock, review the pressure increase over time - finish, record and repeat. As the test went on, part after part, I started joking that normally we close the curtains for this test so that the lab tech can start meditating during the dwell times.

The customer engineer reacted nicely to this, and suggested that it would be worth sending anybody who’s overly stressed to do this test for a little while - half an hour, say. In that way, we get this actually quite pointless test done whilst simultaneously relaxing our colleagues and protecting the lab technician from ultimate boredom.

Perhaps I’ll take him up on that idea - it’s not a bad one at all. Welcome to a new hashtag: #validationzen

The picture above says to me: hydrogen vehicles are always going to be a cludge. Just look at that fuel tank! It’s an aluminium core surrounded by hundreds of layers of some plastic or other - and that’s just one of two tanks in the Hyundai ix35 demonstrator, totalling 144 litres.

I just don’t know. As you know from my previous post, I would love fuel cell cars to succeed, but the challenges to producing a sensible vehicle system and ecosystem are many, and devilishly detailed.

Challenges are what engineering is all about, and whilst I, and no doubt most engineers involved in fuel cell development, could imagine some funky carbon-fibre-clad magnesium tanks reducing bulk, their colleagues in finance will be confiscating their coffee cups until costs are driven down and infrastructure is driven up. Now, I know that separating engineers and their coffee is counterproductive, even under the best collaborative conditions, achieving both will take a few decades more.

Anyway, the article that prompted this post, in the German emobilitytec magazine, about this self-same Hyundai ix35 raised some interesting points:

• The ix35 has two H2 tanks (1 at 100 l + 40 l) totalling 144 l
• Fully tanked, the fuel weighs just 5.6 kg at 700 bar.
• Yes, that’s 700 bar.
• Consumption is 0.94 kg H2 per 100 km.
• The car includes a 24 kWh battery (same as in the new e-Golf), half charged.
  • This is because fuel cells need time to warm up (so the ix35 starts up as electro car) plus time to run down after switching off the vehicle - so the battery needs to soak up the additional charge 100 kW power, Max 124 kW with fully loaded battery, providing a decent 300 Nm
• Good for up to 600 km.

So, power, torque and range are decent, and whilst the volume of fuel being held is large, at least its weight is low. Additionally, you don’t need pumps to get the hydrogen from tank to stack, so on the tank side of things, things are relatively simple. If you discount the difficulties in sealing up the piping between tank and stack under all operating conditions.

That stack itself remains a complex, expensive and still rather fragile mystery to me. And we still need to the extract hydrogen from the environment as sensibly as possible.

Development continues, if not apace. As the European HyFive infrastructure and 110 fuel cell vehicle project shows, industry and politics can combine to prod things forward little by little.

Toyota helped to kick off the 2014 CES show by pronouncing themselves happy with the rate of development and cost reduction on Fuel Cell Vehicles: “Fuel cell electric vehicles will be in our future sooner than many people believe, and in much greater numbers than anyone expected.” Indeed, they intend to have a “vehicle” (by which I understand a car of some sorts) on sale by 2015

Now, even with my occasionally shaky grip of arithmetic, especially in German, that’s NEXT YEAR. Whilst it’s usually better to look forward rather than backwards, the history of fuel cell vehicles is long and far from glorious, so it’s worth taking such pronouncements – even from Toyota – with a pinch of salt.

Having said that, I’ve always been fascinated by fuel cell technology - as a naive young engineer, I somewhat irrationally invested in what in hindsight was a rather dodgy looking British-Belgian-Russian company called Zevco. This firm at least managed to get a fuel cell into a river boat, a taxi (a recurring theme in fuel cells, as a small fleet of taxis created for the 2010 London Olympics shows) and an airport tug - before it folded, with the best of intentions to rise again. Admittedly, I wasn’t the only dreamer out there, as Zevco managed to sign several alliances and intents of work before going under, with companies much richer than I – but there has never been a convincing commercial case for fuel cells. 

More recently, I was naturally keen to be involved in a project to develop the high pressure lines and connectors between the hydrogen fuel tank and the fuel cell. This was, alas, but from a business perspective sensibly, cancelled by our management as – well, quite simply, there wasn’t a convincing commercial case for it.   Money aside, key technical challenges remain:

• H2 infrastructure (and figuring out where the energy to extract hydrogen should come from)
• Tank and system pressures of up to 900 bar
• Operating fluid temperature -40 to + 85 °C
  • When the fuel cell is running at max power, it’s drawing the maximum amount of hydrogen from the tank, thereby reducing the pressure and cooling the feed system to sub zero temperatures
• System permeation & losses
  • Sealing all the lines and connections in such a way that they’re quick to assemble and acceptably cheap
  • Ensuring that you can leave a car in an airport car park for a week without it emptying of its own accord.
• Refuelling safety and losses

Even before sending cars out onto the roads, developing and validating the system is non-trivial as there are only a handful of test centres capable of handling the full suite of tests required. And they’re not particularly cheap.

The fuel cell endeavour seems to go in waves, with resources built up and then, like GM-Opel’s team in Mainz, Germany, discarded. I personally hope that it works out. Perhaps the competitive and commercial might of Toyota, Hyundai, Daimler as well as a range of dedicated system suppliers like Intelligent Energy and Ballard, can result in a compelling case for the technology. But I  fear that, for want of a serious infrastructure, and the insurmountability of storage issues, it won’t.

Still, give me a project working on carbon fibre fuel cell cars, and I’ll be one happy engineer…!