Intro

“What is a camshaft?” was one of my first questions at Musashi AI: a company that is heavily involved in the auto industry. There’s a lot I felt I should have known when stepping into this role, but I quickly realized I’m not assumed to know everything. That after all was the point of a co-op term, to learn; everyone at Musashi made sure I knew that. Here is what a camshaft is by the way:

Musashi was an incredibly friendly place to work and there was no shortage of people encouraging me to expand my knowledge and become a better-educated me. It was endearing. Being my first work placement, I had no idea what to expect. I can say with certainty that any doubts I had about myself were expelled as I was constantly reaffirmed that I’m here to learn, and my willingness to do so was the measure of success.

A lot of my time at Musashi was spent prodding people, many of whom not even on my direct team. I’d prod about the way our AI models worked which naturally planted many questions: “if the AI needs images at this resolution, then how does the optics team deal with different sized camshafts?” I’ll spare the details, but by the end I had cultivated quite a lot of questions.

Over time, I came to realize that these micro-quests for knowledge were not just to satisfy my curiosity, they expanded my understanding of the business, making me a better developer. Learning the roles everyone played gave me insights on how important it is to understand more than your side of the business. Being a developer isn’t just working in a dark room, siloed off from the rest of the team, it requires one to be involved in the business to such an extent that they understand what problem their software aims to solve.

Musashi AI is an interesting company which funnels many facets of engineering together and provides a great environment to learn about software development. By being curious and continuously asking questions, I was able to understand more of the business but also how software engineering interplays with other disciplines in a corporate setting.

About Musashi

Musashi itself started just before the second world war, in 1938, leading it to produce parts for aircraft to aid Japan in the Pacific Theater. Post-war, Musashi then shifted to sewing machines and eventually auto parts. Musashi AI is a subsidiary of Musashi, a joint venture between Musashi and SIXAI founded in 2019. Musashi AI, in North America, then went on to produce the camshaft inspection machine. Now, they have gone on to develop the second generation of this machine, with an entirely new cloud platform to accompany it.

Musashi AI creates automated inspection solutions, but what exactly does this jargon mean on a deeper level, and how does computing come into play? Quite a lot actually; I worked on the team responsible for the Cendiant Quality Insights cloud app. This app works to display information on the status of machines placed in facilities, access billing info, and manage the organization. I would also like to make note of the use of AI in our product – which utilizes deep learning to find and place defects on images. With that said, I am not an expert on AI, and I am not allowed to share much about how it works from my limited understanding. Generally speaking, Musashi AI uses computing to help aggregate data for manufacturers, maintain industrial machines, program how the machine will perform when given a task, and create custom vision models to find defects on auto parts. In the job description section I will go more into detail on the technologies used and my role at the company.

Learning Goals

My learning goals for this work term were: to expand my problem-solving skills, become more literate in the information I consume, and become stronger in my written communication. These goals were chosen because I saw opportunity to expand my skills the most in these areas.

Problem solving is an essential part of a developer’s toolkit, which is why it is the first goal I wanted to refine. This skill is transferable anywhere in the field, and I’m confident that my problem solving was tested and improved over the term as I had the opportunity to work with a whole new tech-stack, unfamiliar to me, to tackle challenges like access control on our endpoints. Looking back at my efforts, I think I was overwhelmingly successful in building my problem-solving skills as I picked up new technologies, created core functionality for our access control, and delved into areas of computing where it was truly new to me; I’ll describe that more in the job description.

In the age of information, being able to extract the right information is incredibly important. The use of AI has highlighted this skill even more, separating those who understand how to grab the important info from those who don’t. My second goal this term was to become more literate in the information I consume, specifically in terms of technology. While I had my coworkers and supervisor to help, I knew I had to become better at picking out the right facts on my own. Thus, I tried to proactively build a hypothesis, research, and then present my findings for review if I was still unsure. This method of approach allowed me to be more mindful of the information I ingested, and to even question those with more seniority than me. This is not to say I will be distrustful, but rather anticipatory in asking questions to myself and others to check if I am able to see what information is relevant and accurate. Based on my success in problem solving, I think that information literacy is foundational to building up a solution and that my success in problem solving reflects success in information literacy.

Being understood is important, and the tricky part about words is that they are more of an art than a science. While formulaic approaches do exist to writing, the main point is conveying an emotion, idea, or feeling. Part of being a developer is communicating ideas to the next person to look at your code; being mindful of their understanding (or lack thereof) and providing instructions to maintain your code. Written communication is something that I have always wanted to improve, who doesn’t want to be understood? It’s in our nature. During my time at Musashi AI, I had the opportunity to write a variety of technical documents ranging from tickets to full-blown research and process documents so the next developer can understand why I made the decisions I did. While feedback was limited due the busy time I joined, the feedback I did receive was positive and I hope the questions that do arise are addressed by my writings.

Job Description

Because I’m still early in my degree, I hadn’t formally studied some of the concepts that appeared in my work. This term gave me practical exposure to them and helped me see why those topics matter in a business.

Many of the credits I have taken are foundational in building up bigger concepts, like distributed systems, cloud computing, and database design; none of which I’ve taken yet. Musashi AI has given me hands-on experience with these concepts in one way or another. I’ve gained experience in these concepts before taking these courses, which I am so grateful for. My work term has allowed me to expand my breadth of knowledge about many aspects of computing relevant in today’s industry, preparing me for diving deeper into these concepts in school while also giving me a framework for how these concepts are applied.

How does this tie into Full Stack then? What did I do at Musashi exactly? As a Full Stack Developer, I had the fortune of being there during a beautifully chaotic period (it gave me independence and ownership), with demos going on, and priorities shifting as things popped up, I was enabled to work on the cloud app, the human-machine interface, and even dabbled in a tiny bit of embedded code.

Full-Stack Cloud App

My primary responsibility was the cloud app; I would work on tickets to help bring the app to polish and tie in features before the demos. I’d do anything from designing the dashboard and creating endpoints querying the database, to adding small yet robust components to support functionality across our app. I even got the chance to work on huge features that have implications for security –and if we get SOC 2 compliance— like an access control system fit with customizable roles, cross tenant database access, and guarding resources based on state. This gave me the opportunity to work Python and FastAPI for the backend, while our frontend relied on Vue and the Vuetify component library. And not to forget the database, which utilized MongoDB (a NoSQL database) as well as MongoEngine to interact with the database on the backend (MongoEngine is an ODM, very similar in concept to an ORM for those familiar with SQL databases).  While I’ve learned full stack development on my own, none of the technologies listed were I directly familiar with: I worked with React, PostgreSQL, and Node.js. A lot of similarities exist between these technologies, but I had to learn an entirely new tech stack for this job.

Full-Stack Human-Machine Interface (HMI)

During the latter half of my work term, I ended up shifting responsibility to help development on the human-machine interface (or HMI). While our machines automated the inspection process, operators are still needed to operate and resolve conflicts with the machine, hence the HMI. The purpose of the HMI is vast, it is used by the operators to work alongside the machine effectively and even engineers to fix and calibrate the machine.

In practice, the HMI exists because automated inspection can happen regardless of whether the rest of the manufacturing line is manual or automated. The difference is simply how the machine is loaded and unloaded. On a manual line, a person places and retrieves the camshaft before and after inspection. On an automated line, a robot may handle loading and unloading, but operators still intervene when issues arise. Either way, there is still some degree of human interaction, and the HMI is the main way operators monitor the system, respond to problems, and keep the inspection process moving.

Moreover, the HMI can be used by engineers to calibrate and maintain the machine. This necessitates an interface between the embedded code and machine to a more granular degree such as moving a motor n steps. The machine’s HMI was also developed using the same tech stack as the cloud application but ran locally and interacted with the database to send information to the cloud. The cool part about the HMI is that it could send commands to the machine using the APIs developed to call the embedded code to do things such as move motors and activate lasers, LEDs, etc. Part of my responsibility was creating components and screens which utilized this API to do things such as send all of the motors to their home positions. One of the most interesting parts of this was being able to test these components and see the hardware responding to the components I made. I was also able to develop a brief few test scripts to condition the machine and summarize data from n runs.

Embedded

While not an overwhelming success, as it was a bit further out of the scope of my abilities, I got a chance to test the embedded code to establish communications between circuit boards by writing a script. Crawling through the embedded codebase gave me flashbacks to my computer architecture class, but had a higher level of complexity that ultimately made it harder for me to pick up in a shorter time frame.

Conclusions

Overall, my term at Musashi AI has made me a better full stack developer. Not only was I familiarized with modern frameworks and libraries, like Vue and FastAPI, but I learned skills that’ll far surpass the lifespan of these frameworks giving me the ability to adapt and learn in any role, not just as a full stack developer. This is something I’m incredibly grateful for; I learned the development life cycle at a real company and was able to contribute to it in many ways.

Acknowledgements

A lot of my learning I attribute to the amazing people who have helped me along the way; both co-ops and full-time employees. Never have I felt like an annoyance trying to learn more about the company and the other departments that I worked in tandem with. I also want to especially acknowledge my supervisor for taking me on despite my lack of experience, I recognize it now and I know in the future I will see that this opportunity is pivotal in my career as a developer and overall software engineer. Moreover, I’m very glad I got the chance to poke around the embedded code thanks to the director of engineering, despite my lack of experience.