Coding for Supply Chain Software

Coding for Supply Chain Software

By: Andrew Gorbaty

Hi! My name is Andrew and I’ve worked as a software developer for about nine years. I graduated with a degree in Computer Engineering and a minor in Computer Science from Loyola University Maryland. Since then, I’ve worked for various companies, including mid-sized places with about 300 people and small startups with teams of less than 20 people. I started my career using C++ on Windows/Mac and rendering technologies like OpenGL to construct real-time graphics engines for Computer Aided-Design software. I also was responsible for creating apps and plugins to integrate data into other renderers and 3D formats.

For the past 2 years I’ve been working with frontend and backend web technologies at a startup which creates supply chain software. I currently design and implement large, asynchronous backend systems which can take user inputs from the UI, email, or a file upload and create, update, or delete order and item information and successfully relay that information to a connected vendor, making buyers and vendors connected without having to sort through emails. A big focus has been changes to this pipeline in regards to AI, and we’re currently making some changes to support systems like OpenAI. Our goal is to help our customers create and update their orders or items from an email with text and PDFs and then our system will understand the email and update their order accordingly.

I also work on a system that calculates if a user has the necessary inputs to build a product based on incoming inventory and orders. You can find out more at Factor’s website.

“My favorite part about being a software engineer is solving incredibly tough problems. It can be frustrating when faced with a situation where you don’t know where to start, but it can be incredibly rewarding to finally find what’s causing a problem, or even better, fixing a long standing problem.”

A concrete example of this is when I was building computer-aided software at my previous job. We had this ongoing issue where zooming in and out on text objects was incredibly slow when text objects were abundant in the scene. It would stall for at least a couple of minutes every time we loaded more than 100,000 objects upon zooming into the model. This was because the text had different textures to represent different levels of detail depending on the current zoom length. Because these text textures kept getting swapped depending on the zoom distance, and we had to wait a long time for everything to get loaded into memory, this system made our software very frustrating to use.

I designed an asynchronous system which addressed this problem. It was able to not only process geometry in parallel, but it was able to upload to the graphics card in parallel as well. Dealing with the pitfalls of this task was really frustrating at first because OpenGL did not have great documentation for working with multithreaded OpenGL contexts. However, after many days of debugging, I was finally able to put something together and load a model with more than 100,000 text objects, while zooming in and out quickly, each containing 3 different texture levels of detail. I was incredibly happy when I was able to demo this successfully and solve a tough problem.

Most of my coding work has a direct impact on customer needs and is mostly feature related work. We recently designed and built a large feature that would allow a customer to create their own email outreach. This feature solves the issue of customers having to contact their vendors manually via email, which can save a lot of time if the customer has hundreds or even thousands of vendors and orders. All of our backend features are developed in Java 17 or above, and some features use the latest coding standards Java has to offer. Some of our code uses the new switch case pattern matching offered in Java 21.

I use docker and bash fairly extensively at my job which provides life to all of our backend services. Our company has built an asynchronous platform which operates by using Kafka Streaming to process application events in backend microservices, or “consumers.” In a docker container you can essentially emulate any operating system, so knowing how to deploy docker containers onto a cloud infrastructure is paramount to our success as a team.

“Knowing how to become a good software developer depends not just on coding a solution efficiently, but also on how well you can design a holistic system where all of the parts work neatly together.”

In a similar light I will also sometimes write scripts to perform convenient tasks, such as a script to batch email sent locally so I can quickly iterate on a feature I’m developing.

Debugging can also take a large portion of my day sometimes. This will involve looking at logs generated by our code via AWS Cloudwatch or running with custom data sets locally to reproduce a given issue. Many times it can be easy to find out what is causing an issue or breaking something, but it’s much harder to find a solution to the problem once you find the cause. This is because many codebases (especially legacy ones) have a lot of existing logic in place, and you don’t want to break any other paths that coincide with the issue being debugged. We usually ensure business logic cases are preserved and are fixed after code changes by creating unit tests (which tests outputs of functions, or “units”) and integration tests (which tests the output of a system when all pieces of software are running simultaneously).

For up and coming coders, I have five key pieces of advice, including:

1. If you want to learn a new skill, come up with a small project idea and implement it on your own time. Large project ideas can be fun but can also be overwhelming.
2. Don’t just rush head first into a problem without understanding the requirements for a given task.
3. Learn how to use Google and search by keywords. There have been countless times in my career where I’ve been saved by knowing how to look up things on Google using the correct search terms.
4. Ask others who know more if you’re stuck. Don’t be stubborn and say you can do it all on your own if you’re lost.
5. If you want a long, successful career in software engineering, be prepared to be a lifelong learner. Learning does not end when you leave school, or even when you leave a job.