Engineering with Empathy: Lessons from My Internship

Collaborative Python Programming: A group of colleagues enthusiastically discussing code on a laptop, highlighting the fusion of empathy and engineering in software development.

What is the true essence of a software engineer? So far in my academic career, this was an understanding I lacked. To many people, a software engineer is someone who can automate and increase productivity. I also discovered software engineers require a heightened level of empathy; a person who carefully crafts the convenience of everyone’s lives at the expense of their own. Throughout this article, I would like to reflect on the subtleties at Red Cedar that pushed me to this realization, as a computer engineering major aspiring to get into embedded software development.

Building Foundations

My journey with Red Cedar started with learning about the workflow of a tech company. I quickly became comfortable with the Office suite and discovered the ins and outs of using tools like Microsoft Teams. The environment showed me how seriously businesses take efficiency, productivity, and collaboration. This short period of acclimation helped me see the bigger picture of my work at Red Cedar. Additionally, I realized any software engineer needs to thrive in fast-paced environments, where planning is often more important than execution. I realized this from looking at DevOps diagrams and the brief daily meeting. From that point on, I knew I needed to take significantly deeper consideration of the projects I took on.

One of my earliest projects was categorizing large volumes of government proposal content. At first, it was repetitive and challenging, but I realized the task carried real value. Organizing past proposals gives Red Cedar a foundation for business intelligence and better decision-making in the future. To me, it felt like understanding how “the wheel was made” before designing the next version. That perspective made the work meaningful.

Tackling Data Challenges

One of the most technically challenging projects I worked on involved handling data from two large-scale LLM datasets. This project is needed so anyone can quickly determine what LLM is best for any given task. This is largely due to each LLM has strengths and weaknesses. I was broadly tasked with scraping tabular data from the web, joining that data with other tables, and outputting a CSV file to an AWS S3 Bucket.

A comprehensive solution architecture workflow illustrating the journey from data collection using Python scripts ran locally, to data storage on AWS S3, and finally to data visualization with Tableau Prep and Tableau.

At First, web scraping was a simple task, but the differences in naming conventions and parameter sizes made the datasets nearly impossible to merge. For example, the model names could be straight forward, [GPT-4o (March 2025)] or have extra noise that needs to be cleaned like parameter sizes, version tags, and dates [Llama Nemotron Super 49B v1.5 (Reasoning)]. By applying fuzzy matching and regex cleaning in Python and Excel, I was able to align most of the models (total 79 and merged 43) and produce a usable dataset, which I then output into CSV format into an AWS S3 bucket.

Here’s a small section of the code I wrote for the scoring logic:

# +0.20 if first token (family word) matches
	a_first = awords[0] if awords else ""
	h_first = hwords[0] if hwords else ""
	if a_first and h_first and a_first == h_first:
		score += 0.20
# −0.25 if next non-numeric token differs and both exist
	a_next, _ = next_non_numeric(awords)
	h_next, _ = next_non_numeric(hwords)
	if a_next and h_next and a_next != h_next:
		score -= 0.25
# small family bonus
	if (afam == hfam) and pd.notna(afam):
		score += 0.03

This snippet shows how I adjusted the matching score based on family names and token similarities. While the logic looks straightforward, it reflects the broader principle I learned: problem-solving in data analytics isn’t just about coding; it’s about making thoughtful trade-offs. You must decide what’s worth keeping, what’s noise, and how to balance accuracy without overcomplicating the solution.

A major lesson during this project was realizing that “boiling the ocean” is nearly impossible and modularity is key. I initially tried to write one massive Python script to handle everything, but it quickly became impossible to follow. With my mentor’s guidance, I broke the project into three smaller scripts: web scraping, joining data, and model name matching. This modular approach allowed me to keep track of what is happening and debug at any point in the code. After that realization, the project essentially finished itself.

Tools and Insights

Using tools like GitHub and AWS reinforced this lesson: both are designed to break work into manageable chunks and maintain productivity. GitHub lets you update and track code incrementally, while AWS provides a streamlined way to access and store data from almost anywhere. These are tools I will continue to use throughout my programming journey.

Another invaluable aspect of the experience at Red Cedar was applying Python to real-world business problems driven by business intelligence. I grew more confident with Python through the help of a business license of ChatGPT and even had the chance to use GPT-5 as soon as it was released in a real environment. Combining ChatGPT’s guidance with hands-on work across LLM datasets gave me an intuition for which models are most effective for specific tasks. Working with this data also gave me a profound insight into the pitfalls of LLM’s. For instance, LLM’s try to predict the next word a user wants to see, this is why LLM’s give responses that may contain nonfactual information. To complicate matters even more, LLM’s publicly available through the internet have a limited number of output tokens. This results in AI often cutting down on response length needed to give a thorough response. On a side note, as someone who carries the weight of people’s convenience, I want to figure out a solution to these problems, so people can have peace of mind when using AI.

Learning from DevOps

A significant influence during my internship was a Senior DevOps Engineer. Through him I learned about the DevOps development cycle and how businesses use Software as a Service (SaaS), Infrastructure as a Service (IaaS), and Platform as a Service (PaaS) to offload tasks to providers. This not only gives companies peace of mind but also lets them deliver value more efficiently to their clients. He showed me how a DevOps engineer takes requirements for an app, website, or software and follows the most efficient path to completion using a mix of in-house and external tools. Through him, I gained familiarity with GitHub, Git, Office, and AWS in a business context. As a computer engineer, understanding this modern development cycle will be crucial for my career in the tech industry; not only for efficiency, but also for providing quality services and products to clients and customers.

Closing Reflections

Though short, this internship was an invaluable experience in strengthening my skills as a computer engineer. I learned about broad areas such as business intelligence and DevOps while gaining hands-on experience in Python development, data analytics, and Excel workflows; all while checking in daily with my boss to present progress. I believe anyone pursuing a career in tech should take on a personal project that exposes them to the full development pipeline and technology stack. Any person in tech should be becoming adept in the usage of AI to get ahead in this era of exponential productivity, development, and collaboration. Finally, my advice is simple: take on projects that expose you to the full stack, and learn to pair technical skill with empathy. That balance is what turns code into impact.