Software

Starting in 2006, I started teaching myself C++ in 10th grade at 14 years old. I quickly became enamored with the freedom and creativity I could explore while also using my math skills that I enjoyed building in school.

​My professional career in software engineering began at a charitable gaming company where I wrote the backend and embedded software for the electronic pulltab product. This was a Microsoft and C# shop. I learned a lot writing POS software, integrating with servers, communicating with thermal printers and bill/coin acceptors. I even had to devise a way for the other developers to interact with LCD screens. Needing to update the firmware on the LCD screens, I began my journey into DevOps where I wrote pipelines to build and deploy the firmware with no internet connectivity. Solving this issue with some electronics running on an embedded device, I then moved on to streamlining our entire build and deploy process. I had to overcome many challenges, including building unity games on a build server and deploying them to a QA environment.

​

My experience here led me to taking a role at a DevOps consulting firm, where I got more experience in many industries, and company sizes. I served both new startups and large enterprise clients including Atlassian and Octopus Deploy. I learned that, while every product was different in the problem it was solving, they were all the same in the service I provided. They are all a website and database. The hardest problem to solve in DevOps is the company culture. Changing how they view problems and what should be done to correct them may be counter intuitive to the decision makers and it is my responsibility to advocate for the correct solution and provide something to support my ideas.

Now, I'm working for a health care company making support software for different forms of therapy. As a senior engineer, I help guide teams on the correct processes and concepts to implement to increase their effectiveness and efficiency. Software developers should be able to do what they are already doing day to day, with very little changes to their process, but kick off a whole suite of processes when their work is submitted. As the team accepts more and more responsibility, and the team changes, some of their tasks may change as well. Once they are bootstrapped and empowered to own the pipelines, they should only ask me for guidance and not to make actual changes. My job is to get rid of my job.

​I still like to write software. Occasionally, I'll sit down to write some mods, or explore a game mechanic or concept. This keeps me interested and abreast on changes in software patterns. If you like software blogs, consider buying me a cup of coffee.