P ROGRAMACIÓN WEB

Students and novice engineers often think that . . .

Research, and the actions of expert engineers, demonstrates that . . . Interaction between people has nothing

to do with engineering: that’s psychology or management. If it’s not a technical issue, then it’s a management issue, not an engineering issue.

Engineering practice relies heavily on people: engineers need help from other people and only create value through the work of other people.

Interactions between you and other people will define your success, just as the strength of steel constrains the height of a skyscraper.

Figure 5.14 A hypothetical map of the social network at any one time.⁵⁵Thick lines represent strong relationships with a strong tendency to collaborate. Thinner lines represent weaker rela-tionships: this is where there could be problems within the organisation. People who don’t easily work together and bounce ideas off each other could represent blockages that impede the enactment of distributed cognition within the network.⁵⁶We can see that our young graduate at the centre of the diagram has developed strong relationships with two of her peers and weaker relationships with four others. There are also people in the network with whom she doesn’t have any relationship with yet: for the time being, she will have to work with them indirectly, with the assistance of some of the others. Large enterprises, therefore, require coordination tools and IT systems to enable newcomers to work beyond their immediate work group and find knowledgeable people within the larger enterprise.⁵⁷

Getting used to the idea that you will have to rely on other people is the most difficult obstacle to overcome in this chapter. As an engineer, you will hardly ever lay your hands on the artefacts that your work helps to create: other people will do that. You may not even see them. You and they may be on opposite sides of the globe, and you may have moved on to many other challenges before they are even built.

Engineers rarely perform any hands-on work, as we have already seen in Chapter 3.⁵⁸

I often repeat this advice: if you ever see engineers with tools in their hands, doing something, particularly if they are working on a bridge, then move away to a safe distance . . . quickly. Something unusual is happening.⁵⁹

Engineers rely on highly skilled people: technicians, drafters,⁶⁰artisans, contrac-tors, operacontrac-tors, maintainers, programmers, designers, and tradespeople. These people mediate between engineers and the systems that engineers create and work with. These

can be machines, information systems, process plants, factories, materials, specialised tools, or vehicles: in skilled hands, they all become human extensions of the self.

As an engineer, you will never have time to develop the level of hands-on skill that these people nurture through years of experience. As a civil engineer, you will rely on skilled surveyors to provide the data from which you can begin your design work, skilled drafters and designers to work with CAD systems to produce working drawings, and skilled operators to control machines and vehicles to make your vision actually happen in reality. You may have heard people say, ‘Engineers construct bridges, roads and buildings . . .’, but in real life, engineers almost never actually construct anything for themselves, except perhaps a backyard barbeque.

As an engineer, you will rely on those other people to turn your ideas into reality.

Your ideas can only become useful through the minds, hands, and actions of other people.

Unless you are very experienced, and have legitimately become an expert engineer, you won’t even be able to tell these mediators what you want them to do. Instead, you will be relying on those other people to already know what can be done and, equally importantly, what cannot be done.

The way you interact with other people will determine how effective your engineering contributions can be.

While theories of psychology, management, and other areas of academic knowl-edge can help you, they are insufficient in the context of engineering. I challenge you, if you want to contest this point, to demonstrate that any more than a few pages of this book can be learnt from psychology or management courses.

Why is this?

Management and psychology theories provide useful guidance for working with other people, but they do not take engineering technical expertise and skill into account.

While some theories apply equally well for seamen and software engineers, engineering practice does not fit well with most of them.⁶¹In this chapter, we have just begun to see where and why this difference exists. Engineering technical knowledge is some-thing profoundly different that management researchers and psychologists have found difficult to understand.

We are almost ready to move on and delve even deeper into the special nature of engineering knowledge.

In the next chapter, we will revisit some fundamental skills for acquiring technical knowledge that tend to be overlooked in university courses. By the time you graduate from an engineering course, you should have developed effective learning skills for explicit written knowledge. However, as we have seen in this chapter, much of what you need to learn in the future will be unwritten, implicit, and tacit knowledge, often embodied in artefacts in a way that requires prior understanding to recognise it. For this kind of learning, you need a new set of skills, different from the ones that you used at university. You may think that you are a ‘good listener’, that you have good visual skills, and that you have top-notch reading skills. However, have you ever thought to test these skills? We’ll do that in the next chapter.

Practice exercise 2: Mapping your knowledge network

In the following pages, there is an abbreviated list of some different aspects of engineering technical knowledge.

For this exercise, you need to select an engineering context in which you have first-hand experience. If you are already working, choose one of the main products or services provided by your firm, one on which you are working at the moment.

Otherwise, think of a context that might be related to your past experience or per-haps a project based on your capstone project in the final year of your university education.

For each aspect of technical knowledge listed in the table, try and identify indi-vidual people that you could go to for expert knowledge of each aspect. These people may be in the organisation that you are or were a part of, or they may be outsiders.

When you have completed drawing up your list, try to sketch a network similar to Figure 5.14 that would illustrate the quality of the relationships you had with each of these people, as well as the relationships that the people had with each other.

You can assess the quality of the relationships between each of these people by trying to measure the following aspects of their interactions.

Classify them on the scale of face-to-face meeting time and frequency that follows.

1. More than 2 hours daily

2. More than 30 minutes/day, or more than 2–3 times per week

3. More than 1 hour/week, meet at least weekly, catch up by phone if necessary 4. More than 10 minutes/week, at least once every three weeks, by phone if not

present

5. Meet for 30 minutes–1 hour, every three months or so, by phone if not present 6. Meet on odd occasions, more by chance than design, know face and name 7. People are physically distant (e.g. different cities, countries) but would get together

for at least a meal if they knew they were in the same place at the same time. Typically meet at least once every 6–12 months, but for extended time and conversation. Can be confident that they will reply to each other’s e-mail requests

Now rate the strength of their relationships on this scale:

a) Highest degree of trust and confidence; each would give the other access to their bank account if needed.

b) High trust and confidence; each would recommend them to other people on their contacts list. If they ask them to do something, they could be confident they would help.

c) Medium trust level; each would have some reluctance if the other one asked for contacts, but would provide information, if needed. Each would not be completely confident that the other would help when asked, but they probably would do something, although they may need reminders.

d) Low trust level; each would feel reluctant to pass on names of contacts, might help the other if asked, but neither could not be confident about that.

Now draw a map using these ratings. Draw lines between each person, with the thickness inversely proportional to the number scale 1–7 (i.e. frequent contacts have thick lines). If you can, colour the lines according to the scale: a, b, c, and d.

Survey of Expertise.

Knowledge of product details and components, function and location of each component, and how each component contributes to the function of the whole assembly. social needs, both within the local community and as individual people, understanding client business needs, such as price, financing method, delivery timing, client organisation logistics, represent the product to a client so that decisions can be influenced; knowledge of aspects of the product that are important to a client and how to describe and present these (also see business development aspects).

Applications of the product

Knowledge of how the product is applied and used by the client’s personnel. The client is more likely to have detailed knowledge than the engineers developing and making the product.

Operating the product

Knowing how to operate the product safely and correctly to obtain the desired performance and avoid damage, how to recognise operational problems, how to start the product, how to stop the product and shut it down, how to ‘mothball’ the product for extended storage, how to protect the product from external environment or potential damage, and how to care for the product (other than maintenance).

Maintaining the product

Knowledge of maintenance procedures for individual components and for the finished product, including the labour skills and knowledge required, appropriate maintenance planning and scheduling techniques to be used, spare parts management, procurement, and logistics.

(Continued)

Survey of Expertise. (Continued)

Knowledge of repair methods to restore a damaged product to working condition, including repair methods for damaged materials and components. Modification of the product to obtain improved, even satisfactory, performance in a given application (knowledge of modification methods typically lies with users and may not be known to the makers or producers).

Problem indicators, cues and symptoms can include unusual noises, smells, heat, and visible fragments (chips, smoke, rubbings, flakes, fragments, dust, particles – particles may be attracted or retained by secondary effects, such as wet or oily surfaces). Evidence of heating can include discolouration, burn marks, heat haze, and shimmering, as well as direct tactile contact or temperature indications. Visible damage can include cracks, dents, scratches, marks, rubbing, bends, crazing, discolouration, wrinkling, distortion in light reflections, and burn marks. With electronic equipment signs of trouble can include intermittent failures, heating, and even audible noises. Problems can also be evident from operator comments, even the contents of trash bins, for example, discarded copies from a photocopier.

Failure modes of product

Symptoms suggest specific failure modes, given an understanding of the product and how it operates. For example, a sticking valve in a process plant can cause chemicals to spill from a tank. The failure symptom is spilled

chemicals. The failure mode is a valve failing to operate correctly.

Diagnosis methods for product

Technical methods for collecting data and analysing data to determine the cause of performance loss or failure. This also relies on having a model of how the product functions and relevant physical principles.

NOTES

1. I use the word ‘most’ because there are some engineers who have remarkable in-depth knowledge of more than one major engineering discipline.

2. Various studies (R. F. Korte et al., 2008; Larsson, 2007) and our own (Trevelyan & Tilli, 2008) demonstrated just how much is learnt from others, and how important it is to seek the help of others in the workplace. Eraut et al. (2007) demonstrated this across several professions in a study of engineers, accountants, and health workers.

3. In an attempt to build a theory of engineering practice that provides an intellectual founda-tion for this book, I have argued that ‘engineering’ itself only makes sense in the context of an engineering enterprise (Trevelyan, 2014b). I have departed from earlier definitions, such as Layton’s and Treadgold’s, based on the notion of making practical use of applied science and optimisation (Layton, 1991; Rogers, 1983) or of productive activity to meet human needs (Mitcham, 1991). My observations of engineers at work demonstrate the overwhelm-ing significance of collaboratoverwhelm-ing with and influencoverwhelm-ing others in the context of a formal or informal organisation. To exclude these aspects denies the validity of most of what I and others have observed engineers engaged in. Even though many engineers see these other aspects as ‘not real engineering’, they also concede these aspects are essential and require engineering insight: they mostly cannot be handled by non-engineers. This strengthens the case to adopt a revised definition of engineering based on observed engineers’ workplace performances.

4. Logistics – activities associated with procurement (buying) of components and materials, transporting and storing them, and monitoring their use and consumption to ensure that there are adequate quantities ready to use whenever they are needed.

5. ‘Expertise’ here denotes knowledge and skills that characterise an expert. The fact that consultants are paid for their knowledge input is a form of recognition that marks them as experts. However, there are many other expert engineers in other kinds of employment.

6. Rescher has provided a discussion on knowledge that is easier to read than most philosophical writing (2001).

7. There are many discussions on classifying technical knowledge in the literature (e.g.

Gorman, 2002). Others, like Gainsburg and her colleagues, have classified technical knowl-edge and also when they observed engineers using it (Gainsburg et al., 2010; Henriksen, 2001). This section of the chapter primarily draws on my own research, but I have used excerpts of published accounts to illustrate in different ways how my own ideas play out in practice.

8. This discussion is adapted from an influential paper by Nonaka (1994, p. 15).

9. To do this, try and estimate the amount of computer storage needed for this. Remember that a full-length high definition video movie requires around 10–20 Gigabytes, say 1.5× 10¹¹ bits of information.

10. To learn more, read about different approaches to epistemology, the nature and scope of knowledge, and ontology, the nature of reality, what actually exists, and how we classify different approaches to these ideas. Both are traditionally concerned with propositional or explicit knowledge that can be explained in written language. However, for this discussion, we need also to understand knowledge that influences human action and perception, forms of knowledge that are more difficult to represent with written language.

11. Collins (2010).

12. Polanyi (1966, p. 4).

13. Collins (2010).

14. Ewenstein and Whyte have discussed this in the context of building design (2007) and Ferguson has drawn attention to a similar appreciation for form in mechanical design (1992).

15. The modulus concept in which a design for a particular application is obtained by adapting the proportions used in earlier designs has been widely used since the early 19th century, and can be traced back several thousand years in architecture (Guzzomi, Maraldi & Molari 2012).

16. Susan Horning has described this in the context of the work of sound engineers (2004).

17. Gainsburg (2006; Goold, 2014).

18. Razali & Trevelyan (2012; Sternberg, Wagner, Williams, & Horvath, 1995).

19. Latour (2005, pp. 204–209).

20. Shippmann et al. (2000, p. 712).

21. e.g. Bucciarelli (1994, pp. 133–135).

22. SAP: One of the most widely used enterprise resource management software systems, commonly used in large enterprises.

23. http://www.mech.uwa.edu.au/jpt/pes.html.

24. Known for the idea of communities of practice (Wenger, 2005).

25. Prior learning needs to be reactivated in order for it to be useful, and connected with the procedural knowledge needed to apply it (Ambrose, Bridges, Lovett, DiPietro, & Norman, 2010).

26. Schön (1983, pp. 184–187).

27. Vincenti (1990, Ch. 5).

28. Orr (1996).

29. Dahlgren, Hult, Dahlgren, Segerstad, & Johansson (2006); Eraut (2007); Eraut, Alderton, Cole, & Senker (2000); D. M. S. Lee (1994); Martin, Maytham, Case, & Fraser (2005);

Moore (1959).

30. Gibbs and Simpson (2004, p. 7) reported that exam assessment is almost unrelated to subsequent recall. Newport and Elms (1997) reported that engineering work effectiveness is unrelated to academic assessment. Lee (1986) reported that academic performance was unrelated to engineering graduates’ performance in their first job as assessed by supervisors.

31. For a review of these studies, read Wenke & Frensch (2003).

32. We are still working on this research.

33. Wilde (1983).

34. Wong & Radcliffe (2000).

35. Guzzomi, Maraldi & Molari (2012).

36. Ravaille & Vinck (2003).

37. S. Barley & Orr (1997).

38. Doron & Marco (1999).

39. Orr has described technicians troubleshooting (1996, pp. 98, 105, 114) with remarkable parallels in the work of sound engineers (Horning, 2004). We can clearly distinguish engi-neers whose work leads them to become highly engaged with machinery and systems in performing their work, often acting as intermediaries or mediators for other engineers who work with more elaborate social networks.

40. Winch & Kelsey (2005).

41. Mason (2000); Prais & Wagner (1988).

42. Button & Sharrock (1994).

43. Lam (1996, 1997, 2000).

44. Tethering – the goats had loops of rope around their necks. The other end of each rope had another loop, which was attached to a stake in the ground. Each goat was free to walk around the stake but could not go further than the length of the rope allowed.

45. Mukerji (2009).

46. Rachel Itabashi-Campbell and her colleagues revealed that earlier studies identifying

‘bounded rationality’ applied equally well to engineers in problem-solving situations. Engi-neers had great difficulty in expanding their thinking boundaries beyond their immediate

day-to-day job concerns. Successful problem solving, it turned out, only happened when engineers were able to accomplish this, and ‘see the bigger picture’. This requires consider-able learning and effort, and the opportunity to set aside normal organisational constraints (Itabashi-Campbell & Gluesing, 2014).

47. CMMS – computerized maintenance management system.

48. Leonie Gouws, personal communication (2012).

49. KPI is Key performance indicator, a quantifiable measure of personal or organisation performance.

50. For a detailed explanation in the context of engineering philosophy, see Goldman (2004).

51. European languages typically contain only about 15–20 terms for brother, sister, father, mother, uncle, aunt, cousin, grandfather, grandmother, great uncle, great aunt, brother-in-law, sister-in-brother-in-law, father-in-brother-in-law, and mother-in-law.

52. Collins (2010) and Polanyi (1966) provide interesting and thought-provoking discussions on tacit knowledge and its manifestations.

53. Brown et al. (1993).

54. Distributed cognition, distributed creation of knowledge, or what Gibbons and his col-leagues have classified as ‘Type 2’ knowledge production (Nowotny, Scott, & Gibbons, 2003) has been discussed in the context of technical work since the 1980s and possibly ear-lier than that (Hutchins, 1995). Unlike Navy crews, however, engineers don’t necessarily know what others know. For a discussion in the context of design, read Larsson (2007) and see also Eraut (2000). Rachel Itabashi-Campbell and her colleagues explored this in a study of engineering problem solving in the automotive industry (Itabashi-Campbell &

Gluesing, 2014).

Hutchins’ model of distributed cognition has limited applicability in the context of engi-neering practice. His case study, an aircraft carrier entering port, describes the roles of

Hutchins’ model of distributed cognition has limited applicability in the context of engi-neering practice. His case study, an aircraft carrier entering port, describes the roles of