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 minds1 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.
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.
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.
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).
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.
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.
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…)
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.
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?
In our minds… our own individual centre of language and imagery, of models of reality that our senses track and tune and - our greatest trick - prepare to communicate to others. It’s because our minds are set up to register and interpret tokens of communication in the vernacular of communities that we have such difficulty teasing apart the different “modes” in which the objects of our engineering undertakings are present to us and referred to by us. ↩︎
There’s another weird philosophical word for “thingifying” something: reification. It always makes me think of kings and such, so I don’t like to use it, but now that I’ve written it here, it’s done, and it wasn’t so bad. ↩︎
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.
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].
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.
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.
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.)
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.
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…}
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:
A validation engineer needs to combine all of those attributes.
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.
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.
The Literal Engineer
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.
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
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.
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.
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.
The passive voice is intended to portray the investigation as being impartial. This:
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:
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!
…an attribute which this post could not be accused of possessing
Cycling back home from the industrial estate where I work in an otherwise romantic Heidelberg, I cross a bridge that soars over a main road with its gemütlich evening rush hour jams, and, in the same leap, over an idyllische railway line to Mannheim. The bridge, though acting here only as the scenery for the introduction to this post, would be worthy of a blog post itself in the hands of one more knowledgeable and appreciative of its design. It is certainly more complex than normal, with a second cycle path spiralling up between road and rail to meet mine.
The thing is, when I’m cycling back from work, this tributary deposits riders cycling up it directly onto my side of the road. This isn’t of itself a problem - I can move over to leave them room. But when I do this, we both end up cycling on the wrong side of the road, also known in England as the correct side of the road.
Over the years I have imagined myself commenting to the other riders: “Oh, you’re English too?” Only I’ve never dared. Not only because I’m quite so brazen, but because the grammar of saying it in German is so tricky to get pithily right that we’ll have crossed before I’ve had a chance to parse it, especially if the person on the other bike is a lady.
Yes, it is with a weary sigh that I note that German, like Latin and some others I could probably research for you, is a language that feels the need for three genders. Echoing our stereotypes of German structuredness, the language can be viewed as a series of matrices, with lattices of cases and word endings that can either be viewed as ladders to a higher plane of language, or linguistic snakes that will land you in grammatical trouble wherever you misstep.
Mark Twain certainly had great fun pointing out the bizarre logic of this supposedly highly logical language in his essay “The Awful German Language”
What this baroque structure does offer is an unusual form of efficiency. Word endings become signifiers to what action is being done by whom to what, if at all. So, in the name of efficiency, I could refer to an English lady as an “Engländerin” - two distinct words implicated by the ending of just one.
The flip side of that efficiency, however, is a certain fragility: if, after drafting a phrase, I want to change the subject noun to a word of a different gender (or, in the more likely scenario, I find that the gender I had assumed was wrong), I have to wade back through the whole sentence, changing and correcting word endings scattered throughout it to something different. If I was fed up with Eine kleine Nachtmusik I could go for a small nightcap instead - Ein kleiner Schlummertrunk, meaning I have changed all three words in that sentence (and that’s without the accusative case of me actively wanting one, which would end up as Einen kleinen Schlummertrunk…)
So German and its relatives are efficient when things go right, but each error results in a cascade of compound grammatical catastrophes. I find English to be more robust to errors: a glitch in one portion of a sentence doesn’t have to mean a complete rewrite. “The” is “the” whatever grammatical chaos is going on around it.
So this post is really all about efficiency and where it should be applied.
There seem to me to be three distinct strategies available:
Mechanical components are generally efficient in one way, but if they go wrong, they are broken and need to be replaced. Highly-strung systems will also break with the loss of a first component, and may even result in losing a chain of components, as in a German sentence.
Systems can add robustness through redundancy. This is generally at the cost of efficiency, but usually can be said to be efficient enough.
Enabling functionality in multiple ways is reflective of the organic, of the free-form, of the gnarly - yes, of language, too. It’s not often possible to attain this in mechanical engineering - I’m struggling to think of an example here, but perhaps sacrificial anti-corrosion coatings is one, where a scratch leads to corrosion of one material that results in the protection of another.
But when we’re designing our product, irrespective of its apparent simplicity, we can always consider the efficiencies going on around it. We need to design for safety, for cost-efficiency, for energy efficiency - for a product’s whole lifecycle. And if we can step away from the fragile and towards the organic in considering the world our product inhabits, we can perhaps go a long way towards attaining the maximal efficiency over the long term. Nature managed it, anyway! Escaping from the semi-philosophical and going back to my bike problem; because of this ability in German to feminise words, either I could ask “sind Sie auch Engländerin?”, which would be efficient, but would, through that word auch meaning also imply that I was also female, or I could ask “sind Sie auch Engländer?” implying that she was male. Mixing things up to avoid the problem ("kommen Sie such aus England?" - do you also come from England?) would be an option, but none of the alternatives is as concise as the original thought.
So I have never dared ask… And I expect that’s fine by the good ladies of Heidelberg.
This post was first published over at Engineers Looking For Stuff, to which I contribute every now and again. I enjoyed writing this one so much, and it’s so pertinent to the way that I think about engineering, that I asked and received permission to republish it here. They are my words, after all!
Engineers have an often uneasy relationship with words. The common assumption is that if left to our own devices we'll mangle grammar, butcher words and generally leave a trail of linguistic destruction in our wake. This is largely unfair, as stereotypes tend to be, but we are rightly better known for our smithing of iron than of prose. If we think about language at all, it's usually in the sense of grudgingly having to cope with it, or even wishing it away: "we shouldn't bother too much about writing - it's the product that counts."
It’s true that product reaching customers is the goal of all our efforts, but words play such a large part in helping us get there that it would be a shame to scurry away from them, as if they were rain and we had no umbrella.
Instead, we should embrace words, using this rain like farmers rather than bankers - because we use them a lot. In our concept proposals, our offers, our specifications, our emails, our reports and even on our drawings, words carry meaning and intent to others. And, usually, these documents have our names on them, thus tagging us as author for eternity. How often does our product do that? (The makers among you rightly have permission to feel smug at this instance - but that still doesn’t exempt you from having to use words!).
So pride in a job well done, in the knowledge that good communication leads to good product, should drive a conscious decision to get our writing up to as good a standard as we can - which, of course, means work.
Whether I’m drafting a blog post or a test report, I often feel my mind racing a few words ahead of me, sifting through multiple cascades of options and meaning, every so often stamping on the brakes as I get stuck with a word that hovers on the tip of my (mental) tongue. Even after that flurry of activity, what I “splash” onto the page needs refining, to ensure that it makes sense and - in deference to the reader - gets to the point relatively quickly and painlessly.
This is what I mean by effort, and the onus of that effort should be on the writer. We have to communicate, and, no matter how good we are at sketching and drafting, we can’t escape having to deliver words to others. These words carry meaning and other more subtle levels of meaning: the tone.
All of us write differently depending on the scenario. So, whereas I use the word shall all the time in specifications, you’ll hardly ever see it in my emails.
Whilst specs and drawing call-outs should be dry and almost legalese, riding as they do on the precise definitions of the words we select, emails can be chattier, depending on your audience. It’s always worth considering your emails to be formal documents, however; they have a history and you’ll be amazed how often emails from six years ago crop up when you or others are searching for information on a project or product. That’s the positive spin on this: there is the negative aspect, that you no doubt can also imagine. So always review before sending (think of that “send” button as “Publish Now” and see what an effect that has on your haste).
The spoken word sets the collaborative tone even more starkly. Face to face there are the immediate signals that everybody sends with voice, body language and participation (or lack thereof) in the discussion, which go beyond the scope of this post, but there are subtle, weasel words that can affect the way people think about their jobs. Indeed, these were the catalyst for this very post.
It was in a project meeting a while ago that I first really noticed them. The product required some pre-assembly of a threaded adaptor and the commercial manager piped up with the comment:
“Then you simply need to screw in the adaptor…”
There it was, that word, “simply.” It suddenly struck me how belittling that word was. To him, that assembly was a value in cents. To us it meant: determining the right tightening torque and number of turns, specifying, trialling and commissioning the equipment, specifying control methods, setting up a PFMEA… You get the idea.
Since that meeting I’ve become very sensitive to “simply,” “only,” “just” and their ilk and always point them out to those to carelessly utter them.
We have to watch out for those words everywhere. Imagine what real meaning lies behind the innocent remark “we only changed the process parameters a little bit…”
We should eliminate “simply” from our vocabulary (and help others to do the same) not in the spirit of saying “everything is hard”, but in the spirit of “we value your expertise, we want you to keep on mastering your work, improving it, and yourself. so that our product can rock even harder than it does now.”
What’s in a word? That much can be in a word.