Intro
I’ve wanted to write this post for a bit now - a realization I have had over my exchange semester is the importance of reflection and understanding how I perceive the world, and watching these understandings motivate what I do. Undoubtedly, this also applies to the professional part of my life just as much as the personal, especially as I dive deeper into embedded systems and mechatronics engineering.
The Timeline
I marked the start of my professional embedded software journey in March 2020. I built a startup alongside my friends for telehealth applications and was responsible for the embedded software on an AVR controller. At the time of writing (December 2023), I have been fortunate to have completed various internships at a few companies, notably Tesla Motors, Skydio, and BETA Technologies. I wrote a little bit about my journey in September 2022 here.
Since that blog post, I completed 2 more internships, both working directly on customer-facing software features, unlike the prior ones. These experiences helped me understand that I prefer (at the moment, at least) working on customer-facing features in mechatronic systems, and I like to write code ‘above the HAL.’ Strangely, it feels like I am slowly going to the type of code I got to write with Arduinos - feature-driven and caring about how the component interacts with the world rather than the internals of the microcontroller. This is entirely contrary to my thoughts of what I would be doing when I first started in the field I thought I would enjoy the EE side of it more (and even did an EE internship!), but I seem to be enjoying the higher-level software parts of embedded software these days.
The Realization
Currently, I am on an exchange semester at TU Delft, following courses for MSc Robotics and Control System students. Sometime in September 2023, a realization slowly became clear - there is a very large world out there in embedded software, a vast amount of known unknowns, and perhaps an even bigger field of unknown unknowns. At the encouragement of a few members of a Slack group I am a part of, I drew out a mind map of where my known unknowns are and what I might be interested in learning.
At first, the realization of understanding just how little I know was scary. I felt confused about my knowledge, and overall, I felt scared to assert knowing anything. Researching topics I was interested in felt like it led me further into a rabbit hole of realizing just how much more there was to learn, and this never-ending cycle started to put me in a position of insecurity over the knowledge I thought I knew and had been building over the past few years. In October and November 2023, I had a few insightful conversations with some mentors and people whom I trust to offer advice, which led to a few key takeaways.
Ability != Confidence (and Confidence != Ability)
I have known about the Dunning Kruger effect as a trivia fact (alongside the fact that the majority of drivers believe they’re above average), but speaking to my mentors assured me that this feeling of, for lack of better words, no competence, was a sign of growth and that I had a crucial learning in the process - the ability to recognize the bounds of my knowledge and an appreciation to the depth that technical problems can have. If I had to plot where I was in time on a Dunning-Kruger plot, here’s how it would end up -
I was taken aback by the fast transition from the peak of ‘Mt. Stupid’ into the Valley of Despair - part of this acceleration in knowledge, I think, was in part to having the theoretical fundamentals to question how to do something and analytically consider how a solution was formed rather than simply accepting a solution as a ‘best practice.’ A new environment at TU Delft also helped me explore things from a different perspective than the ones I am generally exposed to at Waterloo and forced me to revisit the fundamentals.
I still believe this graph offers me too much credit on the ‘competence’ axis - I have yet to complete my undergraduate degree and fully expect to find myself replotting these dates at some future time, likely shifting back throughout time. That being said, I have grown generally comfortable with the fact that the feeling of incompetence is not something to be feared; it’s something that I can use as a catalyst to encourage me to learn more about what I don’t know and further use the knowledge of ‘known-unknowns’ to learn on the go if I require that particular skill at a point in time.
There’s a tradeoff between specializing and generalizing.
This is the saddest realization I have come across and one I am still coming to terms with. Outside of embedded software engineering, there are very few topics I know enough about to learn how expansive it is (at the moment, the only other topic is probably aviation). I got into this field because I enjoy making machines and robots move, and embedded systems are a central part of bringing up a control system to make machines move (at least, right now). From the outside, it seems niche, but even within the field of control systems, several specialties need to come together for proper execution. I drew out a stack of broad skillsets from a ‘vertically integrated’ approach here in a typical control system, alongside my confidence in each of these skillsets:
Each of these topics is easily a career’s worth of specialization, and quite a few specialties left out in this stack are just as essential to bring a control system to life. I consider myself somewhat lucky that what I am genuinely passionate about and find fun in designing control systems is contained close to embedded software. Still, I find myself fascinated by topics in autonomy engineering and domains like control theory and networking.
The advice I received is that it’s essential to keep a niche that keeps me marketable, to learn the parts of the industry I find fun, and to invest in learning clusters of topics that are related. The truth is that quite a bit of my experience I have in domains that are not related to embedded software has come back to be quite important in the projects I work on, whether that is the understanding of stress-strain curves, assisting in EE schematic and layout reviews, participating in system architecture, and many more. That being said, at the moment, I find myself occupying titles similar to `Embedded Software Developer,` and I suspect I will continue to build up my niche in writing embedded software for mechatronic targets. However, I wouldn’t be surprised to see myself switch to an adjacent specialization in the future as I gain more exposure to the variety of tasks required,
Find people to talk to about advanced topics
Perhaps I have had a more trivial and easy-to-digest learning, but I frequently encounter questions I struggle to answer. Having people to bug for answers after a rampant Google search yields little results is a vital part of finding out how (and where) to learn, in my experience. Many discords for open-source software (like ODrive, VESC, and SimpleFOC for motor control) are filled with engineers willing to answer insightful questions and provide one-off mentorship or advice. I also occasionally make use of contacts within my network for hyper-specific and general advisory questions alike and see if there are people who they know who might be able to offer me insight into a struggle I am having.
ความคิดเห็น