This blog post was contributed by Steven Bui, a computer science student attending Oregon State University who spent the summer of 2021 with Bright.md’s software engineering team through the Emerging Leaders Internship program. Here are Steven’s first-hand reflections from his summer.
My name is Steven Bui and I am a computer science student attending Oregon State University. This summer, I had the opportunity to be a part of the Application team at Bright.md as a software engineering intern. These past three months have made for an incredible experience and I’ve gained so much insight into the world of software development. In this post, I will introduce the Emerging Leaders Internship program, some meaningful experiences I had during my internship, and my final reflections on the experience.
Making my way to Bright.md: Emerging Leaders Internship
The importance of completing an internship before graduation was always emphasized to me. Internships are an opportunity for students to develop their skills, gain real world experience, and network with professionals in the industry. As a computer science student, my only exposure to software development was what I learned in the classroom. I wanted to experience what it’s like to work at a technology startup as a software engineer.
This year, I was fortunate to be a part of the Emerging Leaders Internship (ELI) program, which centers on connecting students of color with opportunities. ELI gave me the opportunity to interview with several startup companies in the Portland area, including Bright.md. During the interview process, I was impressed by Bright.md’s mission: to improve how health systems deliver care to patients. At the onset of the pandemic, the company launched a free Covid-19 screener that helped patients determine their risk level and reduce the volume of patient traffic to healthcare facilities.
This intersection between software and healthcare stood out to me as the type of work that really does have an impact; I was set on wanting to explore the industry as an intern here at Bright.md.
Internship learnings from 5 key experiences
1. Taking on my first case
After settling in and finishing the onboarding process, I was assigned my very first case. I remember setting up my development environment and taking a look at the codebase for the first time—it was just massive. There were hundreds—probably even more than a thousand—files that lived within the repository; I was used to only needing maybe 20 files at most. The size of the codebase was intimidating, and I felt lost at first. I had to spend quite a bit of time finding what pieces were relevant to the case, and where would be a good place to start.
This first case was as simple as changing a color value for a text field, and knowing it was eventually going to production was exciting. It was a small step and it paved the way for the fun projects that were coming next.
More importantly, this first case helped me learn the typical workflow of an engineer—a process that includes using version control, tracking tickets in Jira, writing test cases, and going through code review. In school, I had only heard of these processes, but now I had the chance to get involved in the day-to-day responsibilities of a software engineer.
2. Participating in Hack Week
Hack Week is an annual event at Bright.md where engineers dedicate a week to work on an idea of their choice. The only requirement is that the idea has business value in some way. Engineers are also encouraged to try to learn something new in their project.
Luckily for me, Hack Week coincided with my internship, giving me the opportunity to bring my idea to life. For my project, I worked on implementing a “medical illustration skin tone swapper,” so patients could customize the images in their interview. The project revolved around using SVGs, a type of image format that is vector-based (which means they are made up of lines and shapes instead of pixels). Unlike JPGs or PNGs, the styling of SVGs can be programmatically changed with code. At the click of a button, you could change the coloring or animation of an image.
On the last day of Hack Week, everyone at the company is invited to the Demo-a-thon, where engineers present their projects. It was amazing to see all of the innovative ideas that people came up with, as well as the realization of projects. Participating in Hack Week was a lot of fun, and it gave me the freedom to explore new technologies that I was interested in learning.
3. Learning coding principles
As I spent more time working with different engineers on the Application team, I began to pick up on the coding principles that they used in their work. Some of these principles came in the form of memorable acronyms such as DRY, which stands for “don’t repeat yourself.” It’s a principle that emphasizes when writing code, it shouldn’t be redundant or repetitive; if you were to make changes to that code in the future, ideally you would only change it in one place, versus multiple places. Principles such as “DRY” capture the idea of eliminating unnecessary code and making codebases easier to maintain.
In school, I wasn’t graded on the quality of my code, or whether or not I applied these principles. For a coding assignment, you could get away with coming up with a quick solution and having poorly written code, as long as it met the criteria. However, I knew that approach was not going to slide now that I was working on a codebase that was shared by many other engineers.
It was also insightful to see my team members put a lot of thought into understanding the implications and tradeoffs between the different possible decisions they could make; this helped me plan out an approach before writing any code. It’s this way of thinking that keeps the codebase easy to maintain and scalable, so engineers can continue to build on it.
4. Working with a design system
Previously, the Application team only had full stack engineers. I was lucky to join at a time when the team had dedicated front-end engineers. As someone who enjoys working with user interfaces, front-end development was something I wanted to explore more of, and this internship was the perfect opportunity for me to do that.
As Bright.md continues to scale its architecture, the front-end team decided that it was the right time to build a design system–a concept that was completely new to me. A design system was described as a “set of connected patterns and shared practices.” In other words, it is a collection of reusable UI components. Components are the individual pieces that come together to create a user interface. They could be as simple as a button or as complex as an autocomplete search bar.
Our design system is comprised of three parts:
- Figma is a UI kit where designers create the mockups for components
- Bright-ui is the codebase where developers build out the components in React
- Storybook is an environment where anybody can view examples and documentation of the components
After working on many different projects, I began to recognize the benefits of having a centralized place where all of the styles and components live. When we started working on a new product or feature, it was convenient to simply import a button or a container so that we could add it to a page.
5. Being placed on a product team
A couple of weeks in, I was placed on a cross-functional product team for a new upcoming product for the company. I had the opportunity to have hands-on experience by working alongside other engineers, designers, and product managers on the same project.
Since I had prior experience working with SVGs during Hack Week, the team encouraged me to take ownership over handling the SVG work on the project. To make each page display a different illustration, I made a component that loads in an SVG image depending on the input it takes in. I also added the infrastructure to allow for the SVGs to be dynamically themed—meaning, if a customer provided a theme color, the illustrations would be able to respond to the color changes.
While working on the product team, I learned that people across other departments don’t exist in their own separate bubbles. A continuous stream of communication and feedback between the different departments was essential to the development of the product. I found myself having to ask many questions of team members to get a better understanding of the requirements. As I worked on the user interface, I had the opportunity to collaborate with the product designer to ensure the look and feel of the product was in line with the visions of engineering and design.
Reflections
As I wrap up my internship, my biggest takeaway is how this experience gave me a realistic view of what software development looks like.
Being a part of the product team at Bright.md has shown me a very different environment than academia. In a field where business needs are always shifting, I found myself constantly needing to adapt to these changing requirements, and there was a lot of figuring things out along the way.
I came into this internship with an idealized vision that everything is planned out; you just stick to the plan and code. However, I found that’s not how things are. Engineers have to adapt because we don’t always have the answers. Part of being an engineer is being able to maneuver around and solve new, unexpected questions or challenges that come up.
Thank you
I’d like to thank my manager Katharine, my mentor Cameron, everyone on the Application team, and Bright.md for making this experience one of the highlights of my summer. Everyone has been so supportive and created a space for learning, growth, and honesty. I’ve been given so much knowledge, experience, and feedback, and these are the things that I will carry on with me throughout my education and career.
I’d also like to thank the Emerging Leaders Internship program for connecting me with Bright.md and making this experience happen.
