I began working at the independent investment research firm Morningstar shortly after graduating from college. Because I was a new graduate, Morningstar placed me in the Technology side of Morningstar’s Development Program (MDP). The MDP initiative encourages new grads who have just joined the workforce to rotate onto different teams to gain exposure to different technologies and work styles.
For my initial rotation (I actually ended up loving my team dynamic and the work so much that I didn’t end up rotating again), I joined the Notes, Notifications, and Alerts (Nerts) squad on the new Morningstar Direct Cloud web platform. The Direct Cloud platform was the new, cloud-based version of a legacy, desktop application, and it was designed to help advisory firms manage their clients.
I worked in a cross-team environment where our frontend/full-stack team was in Chicago (this is the team I was on) and our backend team was in Shenzhen. Our two teams would collaborate frequently on tasks using a variety of communication methods such as Microsoft Teams, Jira, and email.
Most of the teams on Direct Cloud, including mine, adopted the agile methodology. We released new features and bug fixes at the end of a 2-week sprint. We regularly held
sprint planning meetings to plan features for the upcoming 2 weeks
daily stand-ups to share what we did the previous day
mid-sprint showcases (on team level) to demo exciting developments and works-in-progress
end-of-sprint showcases (on an entire product level) to highlight newly shipped features
retrospectives to discuss what went well and what could be improved.
My team consisted of a Product Manager, Tech Lead, UX Designer, Visual Designer, and a number of Developers — I am beyond grateful for their guidance, feedback, and support during my time at Morningstar.
The Direct Cloud platform followed a microservices architecture, and my team developed and maintained 3 capabilities (apps): Notes, Notifications, and Alerts.
Notes — allowed users to create, edit, and delete notes about certain securities. This capability included
a rich text editor for easy formatting
the ability to tag securities, lists (of securities), clients, and groups of clients
the ability to attach images and documents
Alerts — allowed users to configure in-app or email alerts for when certain changes occurred (security price changed by amount / percent, Morningstar Rating of a fund changed, Morningstar released new research about security, etc.). Users could also easily view a historical page of all previously-triggered alerts in a table format.
Notifications — poll-based notification feed on site header tied to the user’s configured alerts. Users could click into a certain notification and learn more details about whichever change occurred (view graphs of certain securities, could read embedded Morningstar-research articles, etc.).
Here are some highlights of the work I did that I’m proud to share:
Set up and added a number of new alert types by consuming our backend’s Java API in our apps’ Node.js layer. Worked with other developers to create a dynamic mapping of alert types on the frontend so that adding a new type would be simple.
Within 4 months of joining the team and learning Vue.js, I spearheaded full-stack development on a new, revised core component, the Alerts configuration modal, which was eventually injected into multiple parts of the Direct Cloud platform. This component was quite challenging to code (it involved many moving parts), but my tech lead and the other developers gave me great feedback and advice along the way (e.g., DRY — don’t repeat yourself, make components more modular and decouple logic so the component is more reusable).
Researched and implemented Vuex for the first time in our codebase. I used Vuex to share filtering logic between 2 complex sibling components on the Alerts app. One component would feature removable tags of which filters were applied while the other component would feature checkboxes of which filters were applied. For this feature, my tech lead encouraged me to take a Test-Driven-Development approach, so I wrote tests before and during the time I wrote the feature code.
With 1 other developer, I migrated all 3 apps from an outdated design system (Morningstar User Interface) to a new one (Morningstar Design System). This work was planned to be iterative over several sprints, where the 2 design systems had to coexist, so it took a LOT of careful treading on our part to determine which components should be migrated first.
One of the first times I was on-call for a feature release at 10pm, the Alerts app didn’t load in higher production environments, even though it had loaded in development environments. It was late at night and it had been a long day, but I powered through and eventually found the source of the error. I worked with the backend team to implement a fix, and we finished by 2am. I’m happy to say we got rid of late-night releases (for better work-life balance), but I’m proud of being resilient in this situation.
To get more hands-on work experience, Technology Morningstar Development Program participants could take on small, side projects — called Stretch Projects — outside of their main role.
In 2018, I decided to take up a Site Reliability Engineering (SRE) project with 2 other Tech MDP participants. Our Director of SRE was inspired by Netflix’s chaos engineering model and wanted to introduce something similar within Morningstar. He strove to help teams prepare for incidents through gamification.
Essentially, one day a week/every 2 weeks, a team would log on to a site and spin “a wheel of misfortune”, which would feature different SRE incident scenarios. Then they would go through a series of timed steps, where each step would involve questions or a checklist of items they would need to complete to get closer to solving the incident.
My teammates and I met up several times to go over requirements and work on the backend in Node.js and database modeling.
I designed and created a simple frontend app with Vue.js and Morningstar Design System. I also coded up “the wheel of misfortune” using D3.js (had to review some high school math and physics for rotating the wheel, haha).
One of my teammates who was more familiar with SRE outlined several different incidents and response checklists, so she built on top of the Vue app. The other teammate was more familiar with AWS, so she led the architecture initiatives — including setting up a CI / CD pipeline together with Jenkins running on an AWS EC2 spot instance (didn’t need to be running all the time since this was a prototype) to build the app.
While we didn’t end up completing the project fully, it was certainly a great learning experience.
One of my favorite aspects of Morningstar was the emphasis on mentorship. When I joined, I was assigned a mentor who was also in the Morningstar Development Program. He helped me get onboarded, helped explain the different products at Morningstar, regularly shared what he was working on, and gave me tons of career advice.
Many of the developers I worked with (on my team and on the stretch project) also naturally became mentors to me and still are to this day!
After some time, I also had the chance to pay it forward and officially become a mentor myself to 2 new MDP participants. Although I ended up leaving shortly after to work on ProfitKit full-time, I hope I was able to help them get situated and feel less overwhelmed during their first few months.
Vue.js — frontend Javascript framework used for building out all of our interfaces and their components
Vuex — for coding up complex state management logic across components in our interfaces
Vue Test Utils + Jest — for testing Vue lifecycle methods (created, mounted, updated), creating + checking snapshots, and mocking state for Vuex
Backbone.js — old sections of the codebase were written in another frontend Javascript framework called Backbone, and we spent time refactoring them to use Vue
Morningstar User Interface (old), Morningstar Design System (new) — proprietary
JavaScript, HTML, CSS (SCSS)
Web Components from other teams (to embed within our applications)
Node.js — service layer to process and transform raw data from Java backend API
Swagger — our backend team documented the backend API using Swagger
In-house middleware layer on top of Express.js
Various in-house APIs — for authentication + authorization depending on different user roles; searching through equities, etfs, managed products/funds
Postman — I regularly used Postman to test our backend API and the in-house APIs before consuming them in our Node layer
Jenkins — for Continuous Integration / Continuous Deployment (CI / CD) pipeline
SonarQube (called just Sonar at the time) — for code quality reports (code smells, duplicated code, test coverage)
Splunk — for searching through logs (helpful for debugging based on certain user account ids)
New Relic — for monitoring important application performance metrics (uptime, latency, error messages + codes)
Lerna — for updating package versions and publishing packages within a multi-package repo
Atlassian Jira, Confluence — we used Jira to maintain an agile board of all our tasks for a sprint. We used Confluence as a product-wide wiki / knowledge-sharing space
Slack, Microsoft Teams — as communication channels within and between teams