Tell us a fun fact about yourself.
I’m a competitive pool player! A lot of the games I play my opponent doesn’t even get a shot! Though it can happen to me in return! I am the Scotland National Manager of University Pool in Scotland
Tell us about your career journey so far.
I always knew I wanted to be a scientist or engineer, from doing such subjects in primary education. While in Secondary school I liked physics the best, then while at university I like Lasers and Optics the most! Afterwards I enjoyed science and research so much I decided to do a PhD to become a Doctor in Physics. Don’t worry if you don’t know what you want to do. Just do what you enjoy, the specifics come at the end of your university career. Good grades will let you do anything you want!
What was your favourite subject in school and why?
Physics. The best thing about this subject is you learn how to take quite complicated things and describe them in a simple way. This is so important for whatever you do in life – being able to describe something complicated to someone in a simple way, where they might not have the knowledge you do. You also gain great insight into complicated things you’ve never seen before might work, before thinking of ways to prove how they definitely work.
What subjects/qualifications/skills are useful for your role?
I didn’t do this at school, but I highly recommend in your own time at the very least – learning a programming language. I didn’t code at school, but I did at University and during my Doctorate. It’s invaluable, I code problems daily. I’m sure your generation as a much better focus on this than mine did!
What is your favourite thing about your job?
Every day is different! We are designing things from scratch, so it’s all new exciting engineering that hasn’t been done before. I also enjoy how much my expertise is trusted. Even though I am young, my qualifications have enabled me to provide useful and accurate insight to the projects I’ve worked on. Leading me to get even more interesting roles in turn! In particular my doctorate has given me a number of highly specific skill sets which make me to go to person in my part of the company for certain things! That makes me feel valued in my role – which is really important.
What is a normal day in your role like?
In almost any technical job like mine the day starts with a tea/coffee and a check of the email. Quite often I’ve answered a few technical questions the end of the day prior that I’ll follow up on. Next I’ll plan what I want to achieve for the day – though this doesn’t always go to plan. Different meetings and pop up, new problems appear, which keeps you thinking on your feet! Quite often I multitask by setting up computer simulations to run in the background. It’s easy to mix things up – if I don’t fancy doing something I’ll get a different piece of work done. We all have trust in each other to get the work done on time in the best way we see fit – a workplace which tracks what you do minute to minute and plans your day for you is not a fun one to work at!
And what does your job title mean?
Systems Engineer is the engineering of how many complicated things fit together. If you were building a rocket ship (which is why the job actually was invented by NASA), it’s impossible to be an expert on everything about it – because it’s too complex. You have need an engine expert, an electronics expert etc. Therefore you need an expert on “putting it all together”. A systems engineer needs a good grounding in many areas of engineering as result. Though at my company systems engineers are often experts at something as well! For example I am an expert on optics and lasers – so I work on those sorts of projects.
Can you suggest an activity that could be done at home that illustrates an aspect of your work?
You don’t really need anything special to do this, its an activity you can do with someone while cooking a meal – that illustrates the importance of systems engineering or requirements.
Lets say you and a friend are baking a cake together. You must give instructions to your friend on what to do – they cannot move on their own. Your friend must carry out your instructions in the most direct and literal way possible.
For example, lets say you want to add two eggs to the mixture: You: “Add two eggs please”
Friend: Drops two whole eggs, shell and all, into the mixture
You: “Drop two cracked eggs into the mixture”
Friend: Drops two cracked eggs, with shell, into the mixture
You: “Separate the internal contents of the egg, from the outer shell, into two different cups”
You: “Pour the cups of internal egg contents into the mixture.
What has happened here is we have broken down what seems like a simple instruction of “adding eggs” into the two most basic components. Separating the contents, and adding the internal contents.
Notice that we have not said “how” to crack the eggs. That is what is called as “making a design decision” which we do not want to do when making system requirements. Because think about it, as long as the egg contents are seperated it doesn't matter how it is done. As long as its done in a sanitised manner – which could be another instruction. We call these kinds of instructions “requirements”
A big part of my job is writing these “requirements” for complicated technology!