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!
Contact Form
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.
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.
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.
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.
ADT Full Time
Start Date: April 2021
End Date: December 2022
Team: Platform Integration
Role: It App Developer
In my most recent job, I was working at ADT for Blue by ADT legacy support and newer ADT+ platform by maintaining the API integrations with Google Home and Assistant, and to a lesser degree Alexa. I also spent a fair amount of time working on the transition from a self-hosted solution to using the Google Cloud Platform with Docker. I enjoyed my time there, but recognized that if I did not finish my Bachelor’s degree soon, my credits would expire and I would have to start over from scratch.
Enova Internship
Start Date: May 2017
End Date: Aug 2017
Team: UK Product Team
Role: Software Engineering Intern
The initial intern project given to me and the other two interns on my team was to implement an Account Home Page redesign for the UK Product. We used Ruby on Rails to create the new Homepage and new API Endpoints to support it. We also worked on a team members Gem for creating a uniform design language across the company using Sass. We finished the project with about 3 weeks to spare and so we were each given individual projects to finish out the internship. My project was to learn Go and develop a microservice as part of the initiative to split up the monolithic architecture into smaller services. I liked to refer to mine as a picoservice because it had a single endpoint to compare data sent to it against a fairly static dataset.
Equifax Full Time
Start Date: May 2020
End Date: Jan 2021
Team: API Platform & OneView
Role: Junior Software Developer
I started at Equifax on the API Product team maintaining the JSON and XML API solution offered for automated credit reporting. Shortly after working on that team, my team lead offered my a role on a new team being created to develop a new project. I was asked because I had the lowest “Bus Factor” and most recent experience with Front End Development. I worked on the new product for about 6 months until most of the department I was in was being replaced with offshore developers. I was the one developer kept on for OneView to train the new developers on how the codebase worked. I performed these duties for another month when my contract expired. If you want to know more about the project, check it out on the Projects tab.
Interactive Intelligence Internship
Start Date: May 2016
End Date: Aug 2016
Team: Quality Assurance Product Team
Role: Software Engineering Intern
This internship was my first experience with Full Stack Web Development. The Front End was a desktop application using Electron and a Java Backend. I did not have a dedicated project for this internship, I was essentially treated as a junior member of the team. I worked on a variety of tasks from rescuing orphaned phone calls, to adding visualization to the keyword spotting service to notify supervisors.
Rose-Hulman Ventures Internship
Start Date: May 2015
End Date: Aug 2015
Team: Computer Vision for Smart Farming
Role: Software Engineering Intern
The project was one of the ongoing projects at Rose-Hulman Ventures. I was given some code that could take an image of a plant and create a skeletal model of it. I was able to use that to analyze the skeletal model to spit out some information about the given plant and cross reference against the other angles of the same plant. I also implemented batch processing so images could be processed as soon as they were loaded onto the Tegra Board.