Interview With Software Engineering Specialist Jon M. Quigley

For our latest expert interview on our blog, we’ve welcomed Jon M Quigley to share his thoughts on the topic of software engineering and his journey at Value Transformation.

Jon has won awards such as the Volvo-3P Technical Award in 2005 going on to win the 2006 Volvo Technology Award. Jon has secured seven US patents. These patents range from human-machine interfaces to telemetry systems and driver aides. Jon has a Bachelor of Science degree in Electronic Engineering Technology from UNCC, an MBA in Marketing and an MS in Project Management from the City University of Seattle. Jon has membership in SAE, Software Test Professional, AIAG and PMI (holding Project Management Professional Certification). Jon also has the CTFL certification from ISTQB.

Can you share a little bit about yourself and how you got into software engineering?

I got out of UNCC with an engineering degree and was hired by a controls systems organization where I developed embedded products. This was not by plan, but I was fortunate to get a job before leaving with my degree. I really enjoyed this work and that is how things go, a bit of luck, and effort, and you end up on an enjoyable path.

What do your day-to-day responsibilities look like at your organization?

It varies, depending upon the role I am taking with Value Transformation. When I write, I will create some state diagrams and process flow diagrams. Team size also impacts the responsibilities, small teams require the individual to carry a larger scope of work. For larger teams, individuals will be responsible for portions of the software, and the coordination of the development is required, this falls under the product management supporting processes of configuration management. Individuals write pieces of the software that must work together after the compilation to perform the customer’s expectations.

What notable software engineering challenges have you overcome? What did you learn from these experiences?

Often time to market constraints severely impact the development of the software. These constraints can encourage the team to cut corners, and the organization to undertake the technical debt. We think we save time by removing development processes, tasks, or objectives. Business pressures can push us to compromise the associated software product development processes. It would be better advised to reduce the scope, focus on what is most important and develop that in a way that the product can be extended in subsequent iterations. This is one of the perks of Agile or Scrum approaches to developing a software product.

What inspires and energises you within your work?

I get a rush when making an embedded product come to life. The hardware of the product with a microcontroller will do nothing unless there is competent software. Each time is a new challenge to accomplish the objective in the face of constraints and the resources available. I find creating things very satisfying. Solving a challenging product (embedded software) or the generation of the product feels like scoring a touchdown.

What advice would you give to someone wishing to start their computer science career?

A variety of product development experiences help, for example, we can learn much about the process of software development by working in several other capacities and spending time evoking the requirements of the customer. There is no substitute for experience in writing software. Learn a language, C is fairly ubiquitous. If you desire to become more connected with the hardware, assembly language is interesting, but not used so much these days, but learning this language is a great hardware education process.

Is there anything specific to your industry that affects your role as a senior software engineer?

The industry and associated risks will impact the processes for developing the product and the software. The higher the risk, the more controls in the product development efforts, more reviews are needed, and more intermediate checkpoints are prudent.

How do you use log and metrics data to improve your workflow? Do you use a log management system or do you find manually parsing and filtering events to be enough to fit your business needs?

We take measurements of things like the rate of accomplishing the features, as best we can as these attributes are not so easy to estimate the amount of time required to develop the product. Though not easy, we still need to attempt this, knowing that what we think, might not be valid. We should expect things to look different than what we expect, and either adjust the way we set about the work, the metrics, or adjust another aspect of the plan.

If you enjoyed this article then why not check out our latest guide to production monitoring tools?