It’s been a few weeks since I started my internship for the Digital Summer Clinic. I’m currently doing a sophomore software engineering internship at Roadsr, a fleet management startup company based here in Ann Arbor.
Basically, Roadsr creates safety technology for businesses to use in their fleet management systems — think smart dashcams, emergency braking, and the like. I work directly with the Chief Technology Officer as well as the founder of the company. That sounds intimidating, and it did feel like it for a while, but after I got over the impostor’s syndrome (because who doesn’t have impostor’s syndrome in tech?), it’s been genuinely amazing getting to learn on the job.
I’m writing this blog to chronicle my thoughts, realizations, learning and everything else that might seem even slightly pertinent to my career. Maybe future me can look back on these and learn a thing or two from their past self too.
Week 1: June 9 – 15
Starting off the internship, my intern partner, Celine, and I had a meeting with Roadsr’s founder and CEO. We learned about the ins and outs of the company, Roadsr’s unique product propositions, and the vision of the company. This session had been really eye-opening; as someone who had personal experiences with driving safety concerns, I resonated with Roadsr’s pitch to make the Michigan roads much safer at all times.
I never envisioned myself in the automotive industry in the past, but learning about fleet management and safety technology had surprisingly piqued my interest. I had experience in the past consulting for an automaker company, but it had never been as technical as my project in Roadsr, which is to implement the function that creates a rolling video buffer from our dashcam prototype. Under the guidance of my supervisor, the CTO of the company, I was pointed in the direction of researching a Python package and its methods to replicate the publisher-subscriber relationship.
As a second-year in the Data Science major, the task had been a little more than intimidating at first — I hadn’t learned about the client-server architecture pattern in software development yet and I wasn’t too familiar with the concept of a messaging layer or even a Raspberry Pi device. Still, I dedicated much of this week to researching, practicing, and playing around with the methods of the package. It was still a little difficult to envision the logic of the function, but understanding the package fully had helped a lot with reconfiguring my plan and goals for the next week.
Week 2: June 16 – 22
I came out of my initial research week with more questions than answers, so during my second 1on1 weekly meeting with my supervisor, I made sure to clarify every question that I had. I managed to clarify abstract, project-specific concepts, such as how the client-server communication pattern might help my project, the Python scripts I might have to run in order to simulate the desired environment on my local machine, and how the logic might look like with all the working components and threads (such as the trigger publisher and image publisher).
I dedicated this week to figuring out the logic, meaning I experimented with the package and testing out hypotheses through working with examples. I also enlisted the help of A.I. to brainstorm a framework for my program — how do these components work alongside each other, how should I structure my files locally? — which helped me jumpstart the pseudo code. I sketched out a very rough drawing that helped me concretize the steps in my logic, and I sent it to my supervisor for approval or any potential changes.
I discovered that it’s much more efficient for me to organize my thoughts visually. Once I drew my plan out, it was a lot easier to put the pieces together. I wanted to get the full green light from my supervisor for the basic logic before I code everything out. There were still a few questions that I needed clarification on, like how many frames per second we’re looking at and how the cloud storage might work, but I decided to ask these in the next meeting.
Week 3: June 23 – 29
As planned, I kept chipping away at my function and finalized my basic pseudocode framework for what the logic might look like. After getting approval from my supervisor, I dove into the basic implementation of my logic so far.
This week marked the week that I realized I’m enjoying the technical work that I’m doing for this internship. Even going into my third year of college, I still wanted to experiment with what career paths I might like or dislike, and I’m starting to realize that I love the evolving nature of a software engineering internship. I wasn’t expected to go into the job as an expert and I barely had experience with any kind of video handling programs on Python.
However, my supervisor and fellow interns in the company had been very patient and supportive with me, answering my many many questions or redirecting me to online resources if they weren’t too sure themselves. I also realized that in the industry, much of the work we’re doing is strategy rather than the technical implementation itself. No one in the industry is fully an expert at computers and engineering and coding; instead, our job is to think about ways to optimize our program and how to turn technical features into business proposals. This internship is helping me figure out the ideal workplace environment for my future, where I can ask any questions and keep learning on the job no matter my academic or career standing.
My project timeline had been relatively lax, but on Thursday, our founder had called for an all-employees meeting which introduced a new, more urgent deadline for us interns. Preparing for the New Mobility Futures exhibition on July 17th, we are expected to have our functions working and ready by then in order to showcase the capabilities and far-reaching potential of our product prototypes. I knew this is important for the company; funding is so crucial for startup companies like Roadsr and the connections at the event would be important.
I met with my supervisor one more time this week, who told me to look into another Python package (ZMQ) that mostly helps to implement the messaging layer — i.e. The main method of communication between our components — using a messaging queue rather than hosts, sockets and ports. I resolved to look into this for the next week, especially with the July 4th week break during the internship that would give me more time on my hands.
nat's archives 
Leave a comment