Engineering tips, expert engineers, electronics, embedded software, manufacturing

Top Tips for Aspiring Engineers

By: Emma Plumtree

Sales & Marketing Administrator

26th November 2020

5 minute read

Home » Insights » Top Tips for Aspiring Engineers

Here at Plextek we are lucky to have so many expert engineers under one roof, specialising in electronics, embedded software, manufacturing and so much more. We are always looking to expand our pool of expertise and more importantly to help develop and hone an individual’s skills in their chosen field. We take pride in being supporters of STEM studies and offer an invaluable graduate scheme every summer for aspiring engineers. Whilst we have just launched our job applications for the next cohort of Summer Internships, we asked some of our senior staff and mentors for some pearls of wisdom that they have learnt along the path of their careers and top tips they would give their younger selves knowing what they know now…

Nick Hill – On starting any project

Read the exam question carefully.  Make sure you fully understand the problem before you start work on anything.  Question and probe the problem definition you have been given – don’t take it for granted that it is accurate.  Look for areas where the definition is not complete, so your assumption might be different from the author’s assumption.  The further you get into a project the more painful it becomes to make a change of direction.

Kevin Jones – On working effectively

Plan, Plan, Plan – Planning will pay off no matter how great the temptation to hack your latest idea.

Delivery Day – Try to complete end-of-week commitments on Thursdays. If it’s late then you still have Friday to sort it out.

Pretty Ugly – In my first proper job I spent a week creating what I believed was a beautiful user interface only to find it displayed the wrong information. Make it work before you make it pretty.

Do Nothing – Sometimes leaving a device-under-test alone will show more than continually tweaking the device. This helped me find a problem after leaving a controller running for several days.

David Kyle – On usability

The fundamental rules I follow are (1) keep it as simple as you can and no simpler, (2) if it can go wrong it will go wrong, (3) programming languages are not a fashion statement  (4) and think of the next person that has to pick up your work long after you’ve gone.  In other words, is anyone going to thank you in the years to come if they have to fix your thoroughly broken application, and all because you thought the chances of a scenario happening were too small to worry about, and certainly not worth the effort of handling in your 27 layers of abstraction written in a once trendy functional programming language that disappeared five years ago! Remember, one day you might be that next developer!

Alan Cucknell – on seeing through the problem

The best engineers I know display certain habits. One being empathy – they try to see a problem through the customer/installer/remover/user/regulator/stakeholder’s eyes (not just other engineers).  For some reason this is super unusual with most engineers who find it hard to see beyond the technology of a problem. It is also easy for technical folk to say what is or isn’t possible (or cost effective etc).  The best engineers know how to ask the next question (or suggest the next solution) by questioning, testing assumptions, checking understanding.  Even if the technical facts remain the same, much problem solving, and innovation happens by challenging and limiting assumptions and not simply by accepting the world as “yes or no”.

In the Summer before starting Engineering at Cambridge I read  James Gordon’s book Structures: Or Why Things Don’t Fall Down.  One paragraph stood out to me: “I used to lie awake night after night worrying about [the problem], and I attribute the fact that none of these components ever gave me trouble almost entirely to the beneficent effects of worry. It is confidence that causes accidents and worry which prevents them.”  Perhaps in a less extreme way it is those engineers that continue to think about the problem from many different angles and perspectives (and not just a job they did) that I think ultimately succeed.

Peter Massam – on making a difference

I decided to become an engineer while looking at the university courses I might reasonably tackle with my knowledge of maths and physics. I realised that I like the idea of producing things that would affect the way people lived their lives.

To a certain extent I lost sight of that goal at university and in the first few years of my employment. Not that I regretted being an engineer, oh no. I simply took pleasure in solving the challenges I was given – write the software to control the plotter, develop the calibration process…

However, in recent years I find myself looking at the products that I’ve worked on and it feels good to think that I was part of the team that changed the world in that way. It’s what engineers do.

 

With thanks to:

Nick Hill, CEO

Kevin Jones, Embedded Systems Software Engineer / Senior Consultant

David Kyle, Data Exploitation Software Engineer / Principal Consultant

Alan Cucknell, Head of Ignite Exponential – Plextek’s Innovation Unit

Peter Massam – Signal Processing Software Engineer / Principal Consultant

 

We hope you have found this advice useful and perhaps inspired to take the leap into starting your own engineering career!

If you are a student studying for an MEng Degree and are passionate about engineering, are creative, and love learning then head to our vacancy page to read more about the exciting projects you could be working on if you join us here at Plextek.

We look forward to starting the interview process soon and maybe we’ll see you next year…

Here at Plextek we are lucky to have so many expert engineers under one roof, specialising in electronics, embedded software, manufacturing and so much more. We are always looking to expand our pool of expertise and more importantly to help develop and hone an individual’s skills in their chosen field. We take pride in being supporters of STEM studies and offer an invaluable graduate scheme every summer for aspiring engineers. Whilst we have just launched our job applications for the next cohort of Summer Internships, we asked some of our senior staff and mentors for some pearls of wisdom that they have learnt along the path of their careers and top tips they would give their younger selves knowing what they know now…

Nick Hill – On starting any project

Read the exam question carefully.  Make sure you fully understand the problem before you start work on anything.  Question and probe the problem definition you have been given – don’t take it for granted that it is accurate.  Look for areas where the definition is not complete, so your assumption might be different from the author’s assumption.  The further you get into a project the more painful it becomes to make a change of direction.

Kevin Jones – On working effectively

Plan, Plan, Plan – Planning will pay off no matter how great the temptation to hack your latest idea.

Delivery Day – Try to complete end-of-week commitments on Thursdays. If it’s late then you still have Friday to sort it out.

Pretty Ugly – In my first proper job I spent a week creating what I believed was a beautiful user interface only to find it displayed the wrong information. Make it work before you make it pretty.

Do Nothing – Sometimes leaving a device-under-test alone will show more than continually tweaking the device. This helped me find a problem after leaving a controller running for several days.

David Kyle – On usability

The fundamental rules I follow are (1) keep it as simple as you can and no simpler, (2) if it can go wrong it will go wrong, (3) programming languages are not a fashion statement  (4) and think of the next person that has to pick up your work long after you’ve gone.  In other words, is anyone going to thank you in the years to come if they have to fix your thoroughly broken application, and all because you thought the chances of a scenario happening were too small to worry about, and certainly not worth the effort of handling in your 27 layers of abstraction written in a once trendy functional programming language that disappeared five years ago! Remember, one day you might be that next developer!

Alan Cucknell – on seeing through the problem

The best engineers I know display certain habits. One being empathy – they try to see a problem through the customer/installer/remover/user/regulator/stakeholder’s eyes (not just other engineers).  For some reason this is super unusual with most engineers who find it hard to see beyond the technology of a problem. It is also easy for technical folk to say what is or isn’t possible (or cost effective etc).  The best engineers know how to ask the next question (or suggest the next solution) by questioning, testing assumptions, checking understanding.  Even if the technical facts remain the same, much problem solving, and innovation happens by challenging and limiting assumptions and not simply by accepting the world as “yes or no”.

In the Summer before starting Engineering at Cambridge I read  James Gordon’s book Structures: Or Why Things Don’t Fall Down.  One paragraph stood out to me: “I used to lie awake night after night worrying about [the problem], and I attribute the fact that none of these components ever gave me trouble almost entirely to the beneficent effects of worry. It is confidence that causes accidents and worry which prevents them.”  Perhaps in a less extreme way it is those engineers that continue to think about the problem from many different angles and perspectives (and not just a job they did) that I think ultimately succeed.

Peter Massam – on making a difference

I decided to become an engineer while looking at the university courses I might reasonably tackle with my knowledge of maths and physics. I realised that I like the idea of producing things that would affect the way people lived their lives.

To a certain extent I lost sight of that goal at university and in the first few years of my employment. Not that I regretted being an engineer, oh no. I simply took pleasure in solving the challenges I was given – write the software to control the plotter, develop the calibration process…

However, in recent years I find myself looking at the products that I’ve worked on and it feels good to think that I was part of the team that changed the world in that way. It’s what engineers do.

 

With thanks to:

Nick Hill, CEO

Kevin Jones, Embedded Systems Software Engineer / Senior Consultant

David Kyle, Data Exploitation Software Engineer / Principal Consultant

Alan Cucknell, Head of Ignite Exponential – Plextek’s Innovation Unit

Peter Massam – Signal Processing Software Engineer / Principal Consultant

 

We hope you have found this advice useful and perhaps inspired to take the leap into starting your own engineering career!

If you are a student studying for an MEng Degree and are passionate about engineering, are creative, and love learning then head to our vacancy page to read more about the exciting projects you could be working on if you join us here at Plextek.

We look forward to starting the interview process soon and maybe we’ll see you next year…

Top