I've been writing software for quite a while (over 12 years, yikes!) and I love the process of taking an idea and making it a reality through technology. I believe quality software has the ability to change the world and how we interact with it and I'm always looking for ways I can use my skills in software engineering to improve things.
Writing software is great, but writing quality software gives me the warm fuzzies. I'm a huge proponent of test-driven development, so much so that in 2017 I founded a company specializing in teaching and certifying organizations on the benefits of test-driven development. You can check out our website here. We're really excited about transforming test-driven development into something that all developers can (and want to) do!
Over my 12 years working in software I've worked on a vast variety of projects; some awesome and some... less awesome. I've also been asked - or volunteered - to help friends and family with their technology-related concerns. Below are some of my favorite projects, how I contributed to them, and why they stuck with me.The Beta Solution
I was a contributor on a large application that used Angular for the front end. We decided that each piece would be developed separately by individual teams and then brought together as one massive monolithic application. One of the problems we encountered with this process was how we tested those individual packages prior to making them available for consumption in the application. We had more than one case where everything worked locally, but upon publication the whole application broke because of a small defect in one package. I designed a solution using VSTS (our build tool) to publish beta packages to our internal npm feed, then trigger a custom build of the application that consumed the newly published beta package. Using this new solution developers were able to test their published packages on a deployed test environment without changing the production ready packages and potentially crashing the application. Although this seems like something Semver could have handled (and was intended to handle), Semver was unfortunately not an option in our environment so we had to find a different solution.
On the same project, I developed a package that would not only be consumed by the larger application, but would also consume other packages dynamically for display. Those other packages could, in turn, consume other packages and so on down the line. My solution was to create a single (Angular) component and dynamically load components from other packages. The development of those other packages could then be spread across multiple teams, and each team could implement their own components, services, etc. without regard for how everything would fit in the overarching solution. This format enabled our group to quickly develop and deploy new features with very little concern for integration.
While I was assigned to the court system where I live, I ended up being the sole developer of a new system to release (or not) arrestees from jail. We created a process that allowed judicial officers to specify conditions of release and immediately have copies uploaded to the docket (to preserve the record) and transmitted to the sherriff's office to order the release (or not) of those in custody. The application won the Award for Excellence from the state court association as well as an award from the state government for innovation. Knowing I had written something that had a true effect on society at-large was spectacular.
I worked with a large regional health insurance provider to upgrade their member access portal to the latest version of .Net. On the face of it, that isn't a project that would really stand out. What was important about it for me was that it was the first time I worked on a project that utilized (very effectively I might add) test-driven development. Considering that some years later I'd go on to found a company dedicated to training and certifying people on those concepts, this project was a bit of a milestone in my professional development and life. Not only were we able to come in under budget and ahead of schedule, but we reduced detected defects in the user-acceptance testing phase to nearly zero (I think it was actually zero, but I'm not positive so "nearly zero" will have to suffice). It was a great introduction to test-driven development and I often cite it as an example of how I know the process works and why I can be so confident in my zeal to spread it.
For a brief period I worked for a small company focused on crunching data for hotels and hotel chains. I had the opportunity to work on a project to send targeted emails to large groups of users. I can't stress enough that this wasn't spam. So anyway, I inherited the skeleton of the application, but the inner workings didn't... work, actually. I gutted what was there and essentially started over. What we ended up with was a desktop application that could be used to setup the mailing and verify samples, connected to a Windows service on a server that would compile the data and send out the emails. Using the new application saved about 10 hours per week for my coworkers. Now that I think about it, it was the first time I wrote what I consider to be a "real" application and it went off without a hitch.
In 2015 I earned a Master of Science in Engineering in Engineering Sciences with a Concentration in Software Engineering from Arizona State University (I love saying the full name of the degree). Although the program was challenging I felt like it really enhanced my understanding of the reasons for doing what I'd been doing for 10 years. It was nice to have the why to go with the what.
I completed my Bachelor of Science in Computer Information Systems from DeVry University (yes, DeVry) in 2005. It was a good starting point for what has become a really fun career. In school I got to experience a little bit of everything (hardware, software, networking) and found that I really like solving problems through technology. Specifically, I like being able to change what computers do to make people happy. That education laid the groundwork for everything I've done professionally since.
I have a blog! And it's even good (disclaimer: I'm biased).
As I've already mentioned two other times, you can check out my company ThoroughTest to learn more about test-driven development. We keep the blog up-to-date with a new post once a week on various subjects related to test-driven development.