The IET is carrying out some important updates between 17-30 April and all of our websites will be view only. For more information, read this Announcement

Rules and Guidelines
Want to participate in the discussions? Please read our Community Rules and Guidelines. Need some help? Visit Support and Answers.

  • State Not Answered
  • Locked Locked
  • Replies 28 replies
  • Subscribers 13 subscribers
  • Views 2774 views
  • Users 0 members are here
Options
You may also be interested in
This discussion is locked.
You cannot post a reply to this discussion. If you have a question start a new discussion

You don't need practical skills to be an engineer

Andy Millar
Hi,


Ok, that's a deliberately provocative thread title, but it's one I'm willing to defend. But let's go back a bit first...


There have been various discussions on these forums over very many years where someone says in passing statements such us "CEng now needs a Masters degree, but Master students come out with no practical skills". Of course I'm paraphrasing greatly, but I'm sure people will get the idea. Similarly I've heard the view expressed at many engineering gatherings of "our graduates come in not knowing how to solder / use a spanner / wire a plug". Now I'm sure often these statements are perfectly true for many of those entering the engineering profession, the question is whether it matters. And I'd argue that much of the time it does not, and that it's important that we debate this. (Hence this thread!)


To give my own perspective on this, my background is as an analogue audio frequency design engineer, with my postgraduate entry level jobs to this role being as a maintenance and then test engineer. Back in the 1980s I did need to dismantle, solder, and mantle again. My first development roles were based around soldering irons and test equipment. By the early '90s my analogue development team was based around modelling tools, our prototypes were surface mount, and although we used manual test equipment the amount of building  / modifying we did was tiny - and ideas and the ability to play around with them were FAR more important than practical skills. Then our world went digital. Analogue modelling had improved the performance of our systems 10 fold, digital systems improved the possibilities 100 fold. The digital teams needed no practical skills whatsoever, but my goodness they did  - and do - some fabulous engineering.


Of course, there is still a real world to interface this technology to. And this is where the key word in the subject of this post comes in - that word "need". We do need a proportion of engineers to have practical skills to cope with the real world interface, but we don't need every engineer to have those skills to contribute to a team. For me this is summed up beautifully by my one and only patent (sadly not renewed, eu EP2100792 (A1)  if anyone's interested!). There are five of us named on it, these are:

  • A mathematical modeller

  • A DSP on FPGA implementer

  • An analogue electronic systems modeller / application specialist

  • A hardware developer

  • A manager / systems integrator / systems concept engineer / patent author and general herder of cats (me)


Only one of these needed practical skills. And yet this was an extraordinary engineering innovation. I'm allowed to say that as I didn't do the really clever bits, my main role was to bring the skills together and enable them - and that's the point. None of these people could have come up with the overall solution by themselves, that's why all are named on the patent.


So I would - and do - argue very strongly that an excellent engineering innovation team needs three skill sets within it:
  • Practical skills

  • Theoretical skills

  • Human skills


And the best teams have the best people in each of those areas, working together and respecting each other. So a mathematical modeller knows their system is "garbage in, garbage out", and works with those with application knowledge to help them refine their models. And a prototyping engineer knows their prototype is useless with no software to run on it. And they all know they will make mistakes, and will have misunderstandings, and so managing the human side of the development is vital. Working in this atmosphere of mutual respect is tremendous. Been there, done that. Working in an atmosphere of silos, sneering, one-upmanship, and inverted or verted snobbery is destructive and, I submit to the court your honour, produces poor engineering (by any measure). Been there, done that, left the company (a long time ago).


Now there is an argument, I've used it myself, that practical experience helps develop problem solving skills. And for some engineering activities I would support this. However a lot of modern engineering is based around very deep mathematical modelling, that's how we've achieved the fantastic advances in, for example, communications and data management we have over the past 20 years. So we have to accept that those involved will become abstracted from the "real world", it's then a management problem to manage the interfaces. In my present field, safety engineering, it is a reality that software engineers will implement what they are asked to implement. There's a whole other level first to define those implementation requirements correctly and thoroughly, which requires a different skill set. (And validating is a different skill again.)


So can I propose that we stop saying "engineers coming out of university with no practical skills is a Bad Thing" and similar statements - but I am very willing to support the statement "not enough engineers coming into the profession with practical skills is a Bad Thing".


Thoughts?


By the way, bizarrely my practical engineering skills are now way better than they were in my 20s when I actually needed them for work, partly due to experience, mainly unfortunately due to medical issues at the time. In fact (as one or two of my more "old school" supervisors delighted in pointing out) I was pretty cack-handed. (I just checked, cack-handed is not rude!) I'd like to pass on my appreciation to those enlightened managers who realised that my problem solving skills meant that I was valuable - they just needed to make sure that nothing I touched ever made its way to a customer! There is a VERY serious point here, I could easily have been put off engineering for life with that attitude of "you're cack-handed, therefore you're an incompetent engineer". Although I do apologise in retrospect to the The Kinks for any reliability issues in the mixing desk they bought in 1985 which I worked on rather a lot, probably the product that has gone into service which has more of my personal soldering in than any other...I did get one of my more dexterous colleagues to check it over very thoroughly before it went out!


Thanks,


Andy
  • 0
    Apologies, having posted that I've thought of one more important point I'd like to add:


    I have worked with development teams who have produced designs with major "real world" flaws. That is often cited as lack of "practical" skills or experience in that team. I would, in general disagree, I see this as a management problem. If a development team produce something that does not meet the application needs, then how were the application needs defined to the team? To take an example that many of us will have come across, a maintenance engineer says "I'm always replacing this part, I don't know why they designed it like that." The questions this raises for me are:
    • Has the maintenance engineer reported this?

    • Does the organisation have a continuous improvement process for feeding back that maintenance report?

    • Are there technical reasons (or often, sadly, valid business reasons) why this issue cannot be resolved?

    • If so, why have these not been explained to the maintainers?

    • Was this issue picked up in the original design spec? If so, why was it not implemented?

    • If not, how was the application originally specified? Were the right people included in that process?

    • Was the design properly validated?


    Hence the fact that I used to keep myself pretty busy as an engineering manager, there were many stages to go through before I'd blame my engineers! (And still true in my present role as an independent assessor.)


    Right, must get back to work now, looking forward to comments and debate,


    Thanks,


    Andy
  • 0
    • Has the maintenance engineer reported this?
      • No, because there's no procedure to record it.  See below.


    • Does the organisation have a continuous improvement process for feeding back that maintenance report?
      • What maintenance reports?  Nobody else has said there's a problem.  It's just normal wear and tear, or the customer broke it.


    • Are there technical reasons (or often, sadly, valid business reasons) why this issue cannot be resolved?
      • That would cost money.  Doubly so, if the customer is paying for all the fixes.  Spares and repairs can be more profitable than selling the kit in the first place.


    • If so, why have these not been explained to the maintainers?
      • Why bother? The maintainers are the first to know that it's a shoddy design, anyway.


    • Was this issue picked up in the original design spec? If so, why was it not implemented?
      • Design spec?  It worked in testing, so it must be fine.


    • If not, how was the application originally specified? Were the right people included in that process?
      • Not down to the individual part level.  The system as a whole worked fine in testing.


    • Was the design properly validated?
      • It passed all the lab tests, so the design must be good.  It's the users that keep breaking the product.


  • Former Community Member
    0 Former Community Member
    I have always been very practical .. even from an early age. I can remember taking things apart as a child to see how they work. I can remember a very early conversation with my mother, telling her I needed to take my electric blanket controller apart when it was ON or I could not see how it worked. At school, I was lucky to go on day release to a local college (for 2 years) to do Electrical & Electronic Engineering. In the morning, we did electrical installations on wooden boards to the 13th edition (If I remember correctly) and in the afternoon, we did electronics. For my project, I did a sound to light controller (disco lights) and even etched the PCB myself. I went on to do an Apprenticeship with the MOD. It was an excellent apprenticeship, even though my discipline was electronics, we did welding, machining, forging, electrics, software, etc .... it provided a very good base to start a career upon. For this reason, I am a very strong advocate of Apprenticeships. Anyway ... 


    Following my apprenticeship, I started work for a manufacturer of machinery for the paper industry, as a commissioning engineer. On the same day, a guy of a similar age also started, he did the university route. My colleagues job was as a software engineer. Back then, the machines were controlled by a multi card PC system, processor (Z80) and various IO cards. My colleagues, was very clever and could even think (and talk) in assembly code. Sometimes, he was too clever ... his code was very difficult to follow, as he would program in a way that was interesting to him, which meant it was not very easy to follow. During commissioning, if he came out on the shop floor to look at an issue, you could not leave him on his own as he had the 'common sense' of a 5 year old. I came back from a trip once, and popped in to the factory. He had started to commission a machine, as all of the commissioning engineers were away. He had linked out the safety circuit at the safety relay as he could not get the safety circuit healthy. It was a machine that ran at 1500 mpm machine ... not the sort of machine you want to run up with no safety! 


    So my 5 cents ... On the university route, it should be a requirement to do a year with a practical element, like a mini hands on apprenticeship. If you know how things work in the real world (not just on paper, sorry .. CAD or 3D modeling) then this has to be a benefit. I maybe biased, however I do believe you need practical skills to be an engineer.


    Jon (at home, ill with man flu)
  • Former Community Member
    0 Former Community Member
    Interestingly, this is one of the major conversations that we've been having in the IT Industry for the past 10 years or so.


    We've moved from talking about "Unicorns" (Software Developers who understand not just the application they're running, but also the complete hardware and software stack from the OS Kernel up through the network to the presentation on the desktop) to (thankfully!) becoming more interested in "cross-functional teams".


    This is something I've been advocating since my days in the NHS - if you were to go for an operation, you wouldn't expect the ward receptionist to carry out the proceedure any more than you'd expect the surgeon to fetch your post-operative medication from the pharmacy, so why do we constantly bemoan the lack of people coming out of university who don't have "all the things" that we need from day one?


    As engineering moves into the age of the Internet of Things, we're rapidly finding that a successful team includes at least the following disciplines:
    • Customer Care/Tech Support

    • Business Analyst

    • Data Specialist (More than just a database administrator, this person needs to understand how to process and analyse vast quantities of data)

    • Software Developers

    • Hardware Developers (across so many difference areas from RF to Microcontroller design, and Environmental impact to Ergonomics)

    • Project managers (Ideally ones with an Agile/Kanban background, Prince 2 and Waterfall project management is largely dead in the IT industry these days for anyone wanting to get an advantage over their competitors)

    • Systems Administrators (To maintain the underlying data platforms, and no, "the cloud" doesn't remove the need for these people! ;) )

    • Marketing Specialists

    • Sales Specialists


    And that's the team on a "per product" basis!


    There's no doubt at all that bringing together many people with differing skills improves the quality of both process and product - the ability to be able to know everything about the parameters within which you will be operating is a real challenge with so many moving parts of a product!
  • 0
    I have to agree with the original premise here.


    With regards to the counter example provided by Jon; this raises a number of questions:

    - Why did the colleague think he should start the commissioning without a commissioning engineer? It would seem odd that he just thought "oh, no-one's around so I'll just get it done", it suggests to me that he was placed under some sort of pressure to get it done or to impress and, naively, decided to get on with it. Which nicely gets to the second question;

    - Why did he not have any site induction training or, if he did, why did the induction training not cover the necessary practical stuff to keep safe in the particular work environment?

    - If some form of practical training is felt to be required; why assume this to be done by the university?

    - It is easy to blame the university, even easier to blame the colleague; but where were the processes, checks and balances within the manufacturing company?

    - If it was known that this colleage could not be left onthe shop floor on his own as he "had the 'common sense' of a 5 year old"; why was he able to be left on the shop floor on his own?


    So, I agree that you don't need practical skills to be an engineer; but, where a company requires practical skills, because of the kind of engineering they do, they should either find someone with them or provide the appropriate training. I suggest that Jon's colleague had the wherewithall to cross a road safely (being still alive!) and so with the appropriate training would have a) known not to try commissioning on their own and b) how to operate safely on the shop floor; and if not, they shouldn't have been allowed access. (Having mentioned roads; I would also suggest that you don't need to know how to drive a car to know that it'll hurt to be hit by one.)


    My degree didn't include any machine shop practical work but my sponsoring company thought that it was an important skill requirement and organised the appropriate workshop training.


    Cheers,

    Ian.
  • 0
    Thanks Jon for your post (and hope you're better soon!) as it neatly highlights two points. One Ian has already covered, we do regularly as an industry try to fit square pegs into round holes, and then complain that they don't fit. Rather than accepting how well they fit in their square hole, and finding someone else to fit in their round hole.  There is another point hidden in there:

    My colleagues, was very clever and could even think (and talk) in assembly code. Sometimes, he was too clever ... his code was very difficult to follow, as he would program in a way that was interesting to him, which meant it was not very easy to follow.




    That's not a description of a good software engineer, which ties up well with Matthew's posting. Being an excellent software engineer, which includes programming in a way that is useful to the customer, and maintainable in the long term, is very, very, much a full time role. I can think and talk in assembly code, and solve problems in it very rapidly, but I am not a good software engineer - I don't have the skills, knowledge, experience and training to produce sound, structured, maintainable code. So when I work with people who can only do that I really appreciate it!


    Re Simon's post: I agree 100% that is indeed how many companies approach this, and we see the appalling engineering consequences! Validation should be to the customer's needs, not to the spec...but that's for another thread.


    And Jon, I feel really mean raising this when you're feeling under the weather, but the phrase "common sense" always gives me a sensation like fingernails scraped down a blackboard! What it basically means to me is "they don't know what I know really well", but everything we know we had to learn at some point, and we've all learnt different things - luckily. I was thinking when I wrote the first post here about data over telecomms wires: back in the early 1980s "common sense" told us that the maximum speed we'd ever get over it was about 32kbps. The fastest I've come across so far is 800Mbps, and it still seems to be rising. If I had to pick an single example of how ignoring practical experience and common sense, and instead concentrating on pure theory, will achieve something extraordinary, I'd probably pick that at the moment. But of course, I agree with you that we all need to know our limitations, and when to get someone else to do the dangerous bits - and, indeed, how to spot what the dangerous bits are. Although, once again, I'd totally agree with Ian that in an industrial situation that's a corporate as well as an individual responsibility to put suitable safety processes in place. Always worth re-reading the Piper Alpha report to see how even highly trained and experienced people can cause the most heartbreakingly awful situation - it's not a full protection at all.


    Many thanks for all thoughts, let's see what else comes along, meanwhile I'll carry on practically fitting a radiator into my kitchen...


    Cheers,


    Andy


  • 0
    By 'practical skills' you mean doing things with your hands, whereas doing things with your head is something else? I am minded of a school friend of mine, an excellent (mechanical) engineer but with very few demonstrable 'practical skills'. When we were both home from university, it was I who was under his 2CV, patching his blowing exhaust with bits of cut up beer can and stiff wire. His bedroom was tidy with Airfix models neatly arranged on the appropriate shelf, whilst mine was a lab with racks of wire, paint and other 'useful stuff'.

    I would support the contention that 'practical skills' and 'engineering talent' are divisible. I think Stanley Hooker was an excellent example of the 'hands-off' engineer. His autobiography is entitled "Not Much of an Engineer", but his legacy would suggest otherwise.
  • 0
    If we are defining “practical skills” as "hands-on craft skills" then obviously many engineers don’t. Equally if we define “intellectual ability” by proficiency in calculus based science then many engineers don’t need that much either. Most engineering is conducted somewhere on “theoretical v practical” continuum.  The extent of any individual’s flexibility across the range may be limited by various factors including basic aptitude, subsequent learning (including skills not just knowledge), motivational or situational factors.  Using our categorisation there are “Technician” roles where craft skills remain essential and some others where mechanisation has reduced such opportunities (e.g. CNC Machines v Toolmaking).  Once we move to a level removed from hand or craft skills and assume that the individual has more a more developed understanding,then any binary dichotomy between what is “theory” and what is “application” (aka practical) starts to break down.  We could perhaps argue for different optimisation, but beyond a graduate threshold only perhaps at the edge of the continuum is a distinction reliable.

     

    I think at the heart of Andy’ argument is employer’s feedback that “graduates lack practical skills”. What many employers are really complaining about is the graduate lacking sufficient usable skills to make a productive contribution quickly. Graduate salaries are close to the UK average wage, so months or even years of “getting up to speed” can be painful, often only to find that the graduate moves on. Large employers can usually manage this risk but it can really hurt an SME. However some employers expectations are clearly unrealistic. The tradition of much graduate training is to take a brighter than average individual, now mature enough to be self-starting. What they studied often being of limited relevance. For example, the last Trainee Accountant I worked with had just graduated in Physical Education.

     

    The ideal solution to this problem is a Degree Apprenticeship, but it doesn’t look like there will be enough of them to go round anytime soon. The second best solution is for Universities to ensure that some vocational modules and work experience is included. For example some employers complain that graduates can’t use CAD or common design software packages, others that they have no concept of actual equipment in common use. Some former Polytechnics have long been able to tailor their proposition to particular sectors or niches. The model employed in some other countries of a degree only being awarded after supervised work practice could be used, but it is rather against the UK tradition. Also some of those countries have cheap or free higher education systems.                    

     

  • 0
    At the risk of “over sharing”, I thought that I would tell my story of leaving school at the age of 16 to pursue an engineering career. It may not be “typical” but something similar was the common experience of many entering engineering until the 1990s.      

     

    The first year of my CEGB Apprenticeship was spent at college where practical work in mechanical fitting, using machine tools, fabrication and welding, some wiring and instrumentation.  There were two academic streams with some just doing C&G “Basic Engineering Craft Studies” and some in addition doing the G* (Technicians) course. After this you chose to specialise in Mechanical (“the wooden tops”) , Electrical (“the cream”) or Instrumentation (***** potential homophobic abuse). The second year was a 3 month block ( C&G Electrical Technicians course for me) followed by 6 months at the “Plant Training Centre”. This “company college” was superb and by the time you left you knew “inside out” much of the equipment that you would encounter in a modern (nearly new) Power Station, The Head of Department (an HNC CEng) and his deputy, had frequent short sessions on the relevant theory in context for those who were interested. The only thing I didn’t already know when I did a part-time ONC the following year was calculus (apparently so beloved of CEngs). Studying on day release for a Higher Education Qualification (HNC) was less rewarding. However because there were few takers for the heavy current option, I got a lot of electronics which interested me the time, including as a hobbyist with projects from ETI & Practical Electronics magazines etc. This was probably the closest I got to computing, as the 8080A was out. I suppose the nature of my job offered little opportunity to apply mathematical theory rather than just use relevant formulae. Also the lack of time in one day, didn’t allow you to develop valuable “academic attributes” around research and communication skills. For many on the course “General Studies” was just a nuisance subject.  

     

    Having completed my Apprenticeship and HNC, I transferred to High Voltage Substation Maintenance (132-400KV). I  joined IEEIE and negotiated an arrangement where I could swap my hours around to continue in part time-education. I initially hoped to do a part-time Electrical Engineering Degree but there was only one offered within 2 hours, when I inquired I was advised that “because the mathematics content of my HNC wasn’t strong enough there was no advance standing” and the course would be 5 years one-day and an evening. I requested the syllabus and went through it. I couldn’t honestly see how it would benefit me, since it just seemed to be what I already knew “with mathematical bells on” and of little relevance to my work.  An older colleague was pursuing CEI/Engineering Council Exams, which seemed similar but without any teaching.  I chose instead to do a two year course at my local Polytechnic for The Institution of Industrial Managers (formerly The Institute of Works Managers and now CMI). This was worthwhile with significant maths in Accounts, Economics and  Operational Research (statistics). I was assured that an additional “diploma” year would guarantee MBA admission, but I needed a pause in studying to pursue other interests.

     

    I won’t bore you with the rest on my career story, but I became IEng at 27, Chartered in the HR domain (via an MSc), A short-term cover HSE manager (IIRSM Diploma), eventually also that MBA with the OU.  I realised that I had kissed goodbye to the possibility of Chartered Engineer when I didn’t do the Engineering Degree, but my IEng and membership of an Institution of “Executive Engineers” seemed just fine.  Taking a UK-SPEC perspective, I only ever did a modest amount of engineering design, often “on the fly” and never needed any more maths than I had, except to decode the occasional text book.  

     

    Relevant reflections - some for debate

     
    • My early education emphasised knowledge of facts rather than analysis or the presentation of ideas/concepts

    • When I was making career choices, I didn’t know anyone in my social circle who had attended university and I aspired to independent adulthood, earning my own keep etc. asap.  I didn’t know any entrepreneurs either, although a good friend had a successful painting and decorating business by the time he was 20 and another went straight into the family haulage firm. 

    • My practical craft (or hand) skills were mediocre at best, but I was good at more technical work like fault-finding, which required practically applied “cleverness”  

    • I was lucky to find a reasonably successful pathway with no route-map to guide me, but as everyone knows the definition of luck is “opportunity meeting preparedness”, I actually had to battle for opportunity and worked hard to be prepared.

    • I bought my first home at 21 and was head of a small department at 27, I eventually topped out one step short of Director, which I’m sure some would consider “over-promoted”. wink


     

    • Operations and maintenance of high value intensively used assets requires a “bias for action”, much of the time that we might call “practical”.

    • Perhaps research development and fundamental design begin with a “bias for analysis” first which we might call “intellectual”.

    • Within the “Engineering Council family” an analytical or conceptual approach is considered to be “of an intellectually higher order” or “academic”. It is therefore held in higher esteem, than a “more practical” or “vocational” approach.

    • Every minuscule division between every “type” of engineering practitioner usually matters to someone, whether it is part of their self-identity, sense of self-worth, immediate and wider peer group etc.  Starting from that point, a social science frame of reference is often more relevant than a technical one in explaining the difference.

    • We are often very specialised experts until that specialism isn’t needed any more, when our answer quickly becomes “I’m sure I can get my head round that”.  Demarcation was heavily defended by Trades Unions at one time.  Engineering Council Institutions must explicitly not be Trades Unions , but some of the same human needs are being satisfied.  Mutual solidarity can easily be mobilised by any common threat or enemy.

    • Engineering Council’s attempt to “modernise” into the 21st Century by describing its registrants as being “different but equally valuable” was taken as a threat to their status by some CEng who mobilised to squash the concept. Other perceived “threats” treated similarly have included  blocking suitably qualified engineers from Eur Ing and objections to other Chartered designations.

    • The collective desire of Chartered Engineer representatives for status is reasonable and understandable. However, the great majority of them seem confident and successful in their careers, with little need to obsess about relative status. Perhaps all we are seeing is a variation on Car Club members whingeing about Caravaners etc.?  No doubt if handed they were handed reins of power Caravans would be banned on many roads during the day.

    • As far as I can tell without a serious research study the “status” of engineers has not advanced by a (metaphorical) millimetre in my lifetime and may have reduced, despite the academic inflation that has taken place. Perhaps a few who in move in certain social circles are more accepted? It is difficult to compare performance across different eras, Footballers being an obvious example, but given that in Engineering we are all standing on our predecessors shoulders, there isn’t a clear performance improvement either ,is there?              

  • 0

    Roy Bowdler:



    • The collective desire of Chartered Engineer representatives for status is reasonable and understandable. However, the great majority of them seem confident and successful in their careers, with little need to obsess about relative status.


    Roy,

    Well said, I fully agree with your comments. I view my CEng as an indication that I do a good job in a professional manner, no more. It is certainly not a status symbol and I hardly ever refer to it. Going back to the title of this thread, I would agree that you don't need practical skills to be an engineer but also that you don't need theoretical skills to be an engineer. However most engineering projects need both (though not necessarily held by the same person). The person with the practical skills is often as important as the person with the theoretical skills. It the person with the practical skills only were to be awarded CEng on the basis of doing his/her job well and in a professional manner, that would be fine by me.

    I consider that I have practical skills but not using them on a day by day basis means they are not as practiced as the people who normally do the work. Those people should also get recognition, and if it is decreed by ECUK that the recognition is to be called EngTech I will value it as the judgement of their peers that they do good professional work (and similarly for IEng).

    I could in fact go further and say that with the relative numbers of EngTec and IEng to CEng, CEng as the most numerous might be seen as of the least value, but that might stir the pot too much.....

    Alasdair

Join us to get the best from IET EngX.

Joining EngX lets you personalise your experience so you stay up to date on the topics that interest you, plus you’ll be able to make connections who are looking to collaborate, exchange ideas and more.

Join us Not now

Community Rules & Guidelines