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:

(I used the fishbone diagram template in Xmind to create this version) I have also created a separate page for the Phishikawa diagram on this site, here

My hope is that using this as a form of mental scaffolding, I can construct a more detailed analysis of whichever topic I want to consider. But don't worry, I'll try to keep the text chatty and legible nevertheless!

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…

At the very beginning of this blog, one of the questions I asked myself was - what do I do all day? Between cups of tea or coffee, lunch and hometime, I mean.

(an aside; had I not settled down for a cup of coffee and a natter with a colleague recently, I wouldn't have heard of silane coating systems, nor he of critical entanglement in polymers, so coffee breaks do have their uses).

It's a tricky question to answer, in reality. We have where I work a form of time tracking database where we record the hours that we spend on particular projects. I can't extract my own time from each pot, though, so I'd be working on overall team trends, which would only loosely represent my own. Suffice to say I'm not that interested in setting up my own private tracker; for now we'll say that I am pulled in so many different directions, it's difficult to focus on any one activity for any length of quality time. One task that takes up an inordinate amount of time, one that I want to discuss here, is finding things.

Others would refer to it as research, but sticking to the simpler term of "finding" better reflects what I am usually doing. Our labs have produced thousands of reports in the last years. Many are for repetitive tests for series production control or "requalification", lots are investigations into manufacturing or quality issues. Many are validation reports that prove to a customer that we can deliver to an overly complex and largely unchallenging specification. We even have some that are reports on new developments (gasp!). At present, all that good data contained within those reports is effectively fossilised in the hardening goo of Microsoft Word.

How do we detect patterns? Generally, we don't. How do we find the totality of relevant test reports over the years for a given product? I won't say that we can't, but it's harder than just tapping a query into a Desktop Search. We can search and filter through our test database, but that's clunky, too (searching across several years? Forget about it).

So the eternal problem remains eternal - how do we develop the relevant knowledge so that we can design better systems? That's one of the key challenges I think we face.

A small example: recently I had to answer some questions from a colleague in Korea regarding a hose connection. Simple, on the face of it. The connection requires a particular tube endform profile to ease insertion into the hose and to promote the fairly crucial function of sealing. Unfortunately, the drawing he was referring to was created in 2003 and I had no idea where the design principles that led to that particular drawing came from.

I searched and found… another copy of his drawing, but not much else. So, it came down to the oldest of information transfer systems; colleagues. The colleague who created that endform drawing all those years ago still works in my department and ask him I did - but could he remember for the life of him how he arrived at those particular dimensions? No. What and where are our tools? Here's a possible search pattern:

1. Desktop search for anything containing that part number (emails, report, lists, etc) or description

2. Search for reports containing that part number or description

3. Search for reports containing similar parts of a similar description

4. Search for relevant specifications5. Ask colleagues

If nothing interesting is dredged up by that lot, then it's a case of redesigning from scratch. How do we do that?

10. Use Design of Experiments principles to get parts made at various diameters and angles and tested

20. Request some Finite Element Analysis on the joint to ensure that nothing's going to give too soon.

30. Get some fluid dynamics studies done on it to ensure that I'm not overly constricting the joint

40. … umm, file a report somewhere (go back to 1.)

The answer here would then be to link the report to the drawing somehow, either simply by placing the report number somewhere on the drawing, or by placing the link somewhere in the CAD model, or as an additional link or document next to the print on our SharePoint system.

Yes, we use SharePoint. It's clunky and has some great functionality holes at the moment (we're still on version 2007), which means that people don't like to use it. However this, or a dedicated PLM system, is the way forward in terms of linking everything up.

Curation of data is also important. Labelling, Keywording, making more searchable. It's a dull and dry task to start or to perform retrospectively (company librarians required), but if it can become second nature to document control, it could help.

Generally, putting data to use to obtain information, knowledge and even wisdom is becoming ever more important: Big Data is Big Business, as HP proved by stumping up $11.7 bn for Autonomy corp. In theory, using an Autonomy search would be better than hit and hope: hitting the Windows Desktop Search button and hoping that you've entered the right keywords, both in the search and in the document (and praying that the report was written in English by somebody who could spell). But I've only experienced Desktop Search and I don't expect to see such enlightened methods used where I work.

Another tack is social. I am a follower of blog, Confused of Calcutta, run by J.P. Rangaswami who now works for Salesforce.com. He is a true social enterprise and open market evangelist who loves the ways of communication available to us with Facebook, Google+ and their more enterprise-tuned cousins, Chatter and Yammer (an unfortunate name that sounds like the German for "to complain"). The idea behind these tools in the work place is an interesting one. Using my example above, I could write on my wall: "Wondering why this here endform pilot angle is 32° and the other 38° and whether or not it matters in the slightest". The post will be seen by all of my followers and - the theory goes - one of them may know the answer, or know where to find it. Social beats email because the author of the question does not need to think about who a mail would need to be addressed to, who should be "carbon copied" on it and does not need to run the risk of either missing people out or annoying disinterested parties. Social beats email because the act of "liking" or responding to a post broadcasts that action to the connections of the person responding, potentially creating a snowball of knowledge.

However, we all know the downside of our social networks - signal to noise. How can we ensure that the right people even read our question and hold it in their active mental buffers for long enough to action in amongst all the other questions, observations and general banter going on around them? This is where filtering comes in - but filter incorrectly and you'll miss the occasional important missives in the storm.

So, right now, I don't know. In so many ways. If you've used Chatter, Yammer or tools like Autonomy, I'd love to hear from you. Has it transformed the way you work, the way you search, the way you engineer?

In the meantime, I'd best get back to what we engineers do best, which is to… Umm, where did I file that job description?