Thanks For Stopping By!

I'm Billy York. I am a Full Stack Developer currently seeking a Bachelor's of Science in Software Engineering (Fall 2025) and a Master's of Science in Machine Learning (Summer 2026) at Milwaukee School of Engineeringlaunch. I was originally seeking my degree at Rose-Hulman Institute of Technology until COVID-19. In the interim I had moved full time to Milwaukee and did not want to uproot myself to finish the degree, so I transferred. I have worked in a wide variety of Software Development Roles, but most recently my focus has been in full stack web development with a focus on the back-end. If you want to know more about what I've done, you can checkout some of the projects I've made, the places I've worked, or go straight to my resume. If you think I'm the right fit for you, please feel free to reach out!

Thanks For Stopping By!

I'm Billy York. I am a Full Stack Developer currently seeking a Bachelor's of Science in Software Engineering (Fall 2025) and a Master's of Science in Machine Learning (Summer 2026) at Milwaukee School of Engineeringlaunch. I was originally seeking my degree at Rose-Hulman Institute of Technology until COVID-19. In the interim I had moved full time to Milwaukee and did not want to uproot myself to finish the degree, so I transferred. I have worked in a wide variety of Software Development Roles, but most recently my focus has been in full stack web development with a focus on the back-end. If you want to know more about what I've done, you can checkout some of the projects I've made, the places I've worked, or go straight to my resume. If you think I'm the right fit for you, please feel free to reach out!

MySQL vs. MongoDB

SQL vs. NoSQL Database Performance

Tech Stack:

MySQL vs. MongoDB Performance

Summary

This was a class project at MSOE for my Databases course to compare speed and data complexity of SQL and NoSQL Databases. We were required to create a MySQL instance, load it with the given dataset, and create queries to answer specific questions about the dataset, then repeat the process for MongoDB. My solution showed the expected results, it's possible to get both to be efficient with timings under a tenth of a second, but the SQL solution will be much faster until the dataset requires horizontal scaling for processing. We were not working with a dataset that large so SQL was the clear winner with timings under a hundredth of a second with less complex queries. The biggest challenge of the project was learning the Aggregate Function Pipeline for MongoDB. The instructions for the project were a little out of date, giving tips for how to use MongoDB's now deprecated Map/Reduce framework.

Context: Class Project

Time Frame: 1 Month

Team Size: Solo Developer

Role: Solo Development

Analysis

The MySQL portion of this felt incredibly easy, and it's mostly supposed to be simple given that the purpose of the project is for comparison of two systems rather than fully testing our knowledge of how to write the queries. There was a small "gotcha" so students wouldn't just implement the first idea that came to mind, and I luckily thought ahead to account for the case that a director can also be an actor and so the entity to make was a "person" who has a "role" in a movie, rather than "actor" and "director" entities.

Where I Can Improve

I struggled to fully understand what the Aggregate Function Pipeline was, how to use it, and why the Map/Reduce API was deprecated. I needed to pivot my thinking sooner on this project and accept that the information I was given was a little out of date and that I would need to adapt in order to do well with the project.

What I Learned

While I've had some experience with NoSQL Databases before this project, I had not delved into the world of MongoDB yet and the Aggregation Function Pipeline used to build queries for it was easily the most fascinating part of this project. I was surprised at how much faster the database worked when using the pipeline, however there is a part of me that also wonders if a less obtuse API could be developed to achieve a lot of the same functionality without necessarily creating a DSL.

Jekyll Theme

The Theme Built To Make This Site

Tech Stack:

Jekyll Material Design Theme

Summary

I created the Jekyll theme this website is using because I could not find one that used the Material Design Language, with the exception of one who's last update was 6 years ago. So I wanted to make something that I could both use and publish for others to use as well. It will be more extensible than most other Jekyll themes I've seen, but at the cost of a little more involvement from the end user. There are several example layouts, but ideally you will create your own following those examples. In doing so, your website will be unique and tailored exactly to your tastes. There are a few known issues. First, carousels are not working. I intend to fix this with the switch to fully utilizing the Sass components of the MaterializeCSS library. There are some other issues regarding style overwriting that require spot-fixing as they come up. If you find any more, please feel free to reach out.

Context: Personal Project

Time Frame: Ongoing (1 Month So Far)

Team Size: Solo Developer

Role: Solo Development

Analysis

I think I was able to visualize and get a very solid first effort onto the web, especially for someone who considers themselves more of a backend developer anyway. I iterated on the specifics several times before getting the website to a state I'm happy with. I was able to rapid prototype by creating test sections and used mock data to ensure the look and feel were close to what I was going for.

Where I Can Improve

There are definitely some areas I still need to work on, like creating uniform responsiveness and improving the styling on the custom CSS animations I've built. I could have done a better job prototyping, I don't think I'm quite to the point where I can look at a low fidelity mock and decide if I like the design or not yet. I intend to practice when I convert this theme to use MD3 for Web which is currently in development.

What I Learned

I had heard about Jekyll prior to this project and after running into an issue getting webpack to work properly for me, I decided to use it instead of React since I wanted to create a static web page in order to take advantage of CDN's and not worry about running a web server. The Liquid API reminds me a little of PHP in how the logic of building the pages works, the key difference being all of the rendering and string concatenation happens before the page is even request from the web.

OneView

Drag & Drop Credit Report in a Web Page

Tech Stack:

OneView Customizable Credit Report

Summary

After working at Equifax for a couple of months, my team lead tapped me to join a new team being spun up to create a new product. Despite being the newest member to the team, I was the only person on the API team with any experience in front-end development. We were tasked to make a "Customizable Consumer Credit Report" by letting the user drag and drop different sections of the credit report in different orders. We started by working on 3 separate parts. The other Backend Developer started the API the front-end would use, the Front End Developer started making the drag-and-drop framework so by the time we finished the backend we could contribute by implementing individual modules for the credit report, and I was working on a translation layer for the data models coming from the old C mainframe. With those initial parts completed, everyone on the team was working on finishing each of the modules. The final portion required was the creation of a "pretty-printed" PDF of the report so the customer could print it out to see if they liked how it looked on paper. We did this by spinning up a new micro API that took in the ordering system of the modules, rendered it on a headless Chromium Browser, and sent back the print view of the page as a PDF. This guaranteed all PDFs would look the same regardless of the customer's browser.

Context: Work Project

Time Frame: 6 Months

Team Size: 3 People

Role: Primary API Dev & Assistant React Dev

Analysis

This is the project I'm most proud of being a part of. We had a small team, formed and stormed fairly quickly and moved onto performing for the majority of the project's run time. We were able to push multiple builds per day, essentially as soon as we had QA'ed another's work we would get it out so it could be integrated with the cloud platform as soon as possible. The faster we could move to get pieces into the platform, the faster that team could start running full integration simulations and usability tests.

Where I Can Improve

The original primary front-end developer left midway through due to getting a better offer elsewhere and we needed to hire a new person in the interim. Getting them up to speed while I was still learning was a challenge. This experience has lead me to try and grok more than just the immediate codebase I'm working in and document what I do so I can keep my bus factor low. This proved useful when it came time to train my team's replacements once we had completed the product.

What I Learned

I learned a lot on this project. Prior to this I had only done minimal enterprise-level API work with Java, and my front-end experience was very patchy in that I always was learning just enough to complete the project and I decided to dedicate myself to fully learning react for the duration of the project and further. Storybook was also a very interesting live-testing framework we used to be able to mock and stub out unfinished sections so we could give the product team an idea of how the project was coming.

Design Thinking Process

Group Project for Thinking like a Designer

Tech Stack:

Design Thinking Process Group Project

Summary

This was a class project for my Human Centered Design Course. We were tasked with designing a game targeted at MSOE students that would teach them the MSOE Mindsetlaunch. We did this by performing the 4 of the 5 Steps of the Design Thinking Process. We Empathized with our users by conducting interviews, we Defined by creating User Personas based on the interviews, Ideated by Journey Mapping with the Persona, and Prototyped a solution to fulfill the gaps found in the Journey Map. My groups biggest obstacles was scheduling meeting times. We are all active college students with extracurriculars going on, so finding free time to meet outside of class was a struggle. We overcame this by developing an asynchronous method of using our Microsoft Teams chat to communicate, report, and take on more work. We did still meet in person on occasion, but it was much mor effective to use Teams more often than not.

Context: Class Project

Time Frame: 1 Month

Team Size: 4 People

Role: Copywriter

Analysis

This project was a great experience to walk through every step of the design thinking process as if I were working with a team to create a real product. I primarily worked on writing the actual copy while my teammates did more of the visual design and brainstorming of directions to go. They had more experience with the tools we were expected to use like Canva, so I was happy to write out the words that would go on there and learn from them as they created the full visual designs. When it came time to prototype, I did want to cut my teeth on Figma and so I dove very hard into it in order to learn as much as I could about it.

Where I Can Improve

This was my first academic group project in quite some time and I had been accustomed to making myself and expecting others on my team to be available during normal working hours. This was definitely not doable, neither on my part nor my teams' part. It felt like the beginning of the pandemic when everyone started working from home and meetings/office questions turned into Teams chats that weren't necessarily immediately answered because you weren't asking a question face-to-face with someone. It was an exercise in relearning how to work asynchronously with people and while we stumbled a little in the middle, we were able to recover and still get a good grade on the assignment.

What I Learned

I have used and been given prototypes from other sources, but Figma really blew me away in what it can do. The extensibility to create and reuse objects and themes fills my head with ideas for how to prototype some other projects I want to do and I feel motivated to actually perform the prototype stage. While I did not delve deep into it for the first version of this website, I do intend to use the MD3 theme that is currently available when I work on updating my design language to something more modern.

Last Updated: Fall 2024