Cross-Functional Engineer
What is a cross-functional engineer? It is a term I like to use when describing the situation I am in, or who I am and what I do. Back in 2011, I started my mechanical engineering degree at McGill University and graduated in 2016 with a mediocre GPA, and very little interest in doing what I was trained to do. I had developed an interest in software development and had been practicing on the side until I decided to completely switch fields and enter the wonderful world of software development in 2018.
The change was undoubtedly scary, but having a background in mechanical engineering turned out to be a great asset. Why is this the case? After all, even though there are some overlaps, mechanical engineering and software engineering cover quite dissimilar domains. Software engineering problems, especially for the e-commerce industry that I find myself in, mainly reside in the software and information realm, and are abstract compared to the physical problems that other engineering fields deal with. For example, while a mechanical engineer is concerned with fatigue failure, system stability, and material strength; a software engineer is mostly concerned with data integrity, system availability, and resilience.
The similarities show up when we move away from domain specific technical details and look at the methodologies and principles used in designing solutions. In both engineering fields, problems are usually open-ended with no one correct solution, and require a step by step iterative approach. This design process can be summarized with the following steps:
- Defining the problem, objectives, and constraints
- Gathering information
- Designing multiple possible solutions
- Evaluating these solutions
- Selecting, testing, and implementing one of the solutions
It is also not hard to realize that the design mentality between these two fields is quite similar. Both fields require defensive design to protect the systems against unforeseen disruption, and require thorough analysis of the systems’ failure modes, which are referred to as ‘edge cases’ in software engineering.
While I had enough practice going through this design process, I had never applied it in software before my career switch. For example, if I’m required to design a heat exchanger, I know, or knew, where to start the design process, which materials are suitable, which type of heat exchanger works better, specific methods which I can use to iterate over my design and come up with a product that would satisfy the clients’ needs. On the other hand, I now realize that I was subject to the Dunning-Kruger effect at the outset of my career shift as I started software projects. Thankfully, it didn’t take long before I realized how little domain knowledge I had. This lack of knowledge was quite literally crippling as I did not know the necessary tools, frameworks, and technical concepts to be able to break down relatively complex design problems.
To get over my unfamiliarity with software engineering concepts I’m actively studying — but more importantly — I’m learning at work by doing. In the meantime, I always try to draw analogies between mechanical engineering and software engineering concepts to help me retain knowledge and understand better. For example, I usually think of a message queue as a plenum chamber or a water tank. Both of these devices lower the velocity of the incoming fluid, increase the static pressure, and are used to provide a more steady mass flow, and protect systems against sudden spikes or dips. Similarly one reason to use a message queue may be to have more control on the rate of incoming messages, and to protect services against sudden spikes. Understandably, the concepts are not one-to-one, and thus these analogies fall short in many cases. Thankfully, I work with incredibly smart and supportive people at SSENSE, where I can continue to learn and become a better developer.
Editorial reviews Deanna Chow, Liela Touré, & Prateek Sanyal.
Want to work with us? Click here to see all open positions at SSENSE!
