My Path to Programming

My Path to Programming

The very first moment of coding that I remember goes all the way back to middle school.

We had to enter coordinates and color choices into a program and upon execution, a small triangular cursor scurried around the CRT screen leaving a trail of pixels in its wake. Our assignment was to draw a house -- I went the extra mile by drawing a door (complete with doorknob) and a 4-pane window. As a reward for my efforts, I was given some time to play Oregon Trail.

In high school, I mostly used computers for schoolwork or games, although I did hack my parents' email program for fun. I also enjoyed playing games on Atari consoles in my free time.

In college, we didn't have Ethernet in the dorms so I used a 14.4 modem to dial in (yes, the actual modem used is pictured below [I found it while digging around my desk at my parent's house]). This was the start of my experience with the command line -- tab completion, customizing .bashrc with macros, telnetting to MUDs to visit with friends all around the world; good times.

Part of my technical coursework included CIT (computer information technologies) classes; the most memorable of them (and still in use today!) covered relational database concepts and SQL.

After graduating, I ended up in the corporate world for 14 years and oftentimes found my technical background came in handy.

The first company I worked for had a team of people who were performing the same tasks differently. This created efficiency challenges when someone was out as the lack of consistency from person to person meant slower uptake when you were looking at someone else's work. To help remedy this, a good friend of mine (Tyson, my programming guardian angel) and I put together a web-based workflow system (ASP, HTML, and CSS) that helped unify our processes to create a more consistent product.

I still remember the first time I came across one of my colleague's projects that had been created with our system -- it was so much easier to figure out what was going on and it helped me operate much more efficiently. It was very rewarding to have put all that effort into the workflow system and then experience such meaningful results.

A few years later a customer approached me about creating custom reports based on their cloud-based IVR call logs. At the time the only SQL software I had at my disposal was MS Access so I put my head down and got to work. The end product was a series of custom reports that the customer accessed via a GUI dashboard, all delivered via a self-executable Access file.

These experiences were little reminders, refreshers, of what I learned in college and allowed me to dust off my programming skills, and each time I really enjoyed it.

In 2012, though, things got serious.

A year earlier I joined a group of percussion educators in creating a non-profit organization that focused on the development of percussion education through performance opportunities.

This organization, Northern California Percussion Alliance (NCPA), holds indoor percussion competitions in the first few months of every year.

One administrative element of the competitions is scoring and detailed score reporting (called recaps). The operation of the shows went something like this: ensemble performs → judges write down scores on paper → a runner grabs said paper and drops it off with a tabulator → tabulator types the scores into a spreadsheet.

At the end of the event, the tabulator sorts the spreadsheet, double checks with the judges to ensure there aren't any typos or other issues, and then prints out the spreadsheet as the recap.

Ummmm... yuck. That's waaaaaaay too manual for this technology/process geek.

And thus, ShowDay was born.

I went to work teaching myself PHP via PHP.net, the plethora of helpful tutorials out there on the net, and taking classes on Lynda.com. Bit by bit the secure website, forms, and database integration that would capture the judge scores started to come together. That system essentially provided the spreadsheet that we had been creating via manual transcription.

This worked well enough in 2012, but in 2013 a friend of mine who was part of a different, but similar, organization asked what we were using for tabulation and recaps. Ashamed to show him my cobbled together system (a glorified web-based spreadsheet), and knowing full well that the technology was there to do so much more, I worked every available hour for the next 2 weeks and put together the very first full version of ShowDay.

Every year during the offseason I pour time into implementing new features to do more of the repetitive and automatable tasks for us so that running our events is easier, faster, more accurate, and less stressful.

It's now to the point where ensembles can register and pay their event/membership fees, admins create the schedule which exports to PDF for easy distribution, directors enter their performance and ensemble stats to support event logistics, admins upload the judge commentary (MP3s), staff can listen to those commentary files from their mobile devices, and recaps are exported to PDF at the press of a button.

Over the last 6 years, ShowDay has saved people thousands of hours. While I can't give you an objective figure like, "Saving those hours resulted in $100,000 in overall savings," what I can tell you is that people are doing more important things with their time, and that's priceless.

My work on ShowDay has led to other projects for people wanting to take manual processes and replace them with web apps -- realizing the gains of speed and accuracy, and saving time.

I feel very fortunate to have worked with some great people over the years on some significantly meaningful projects that have saved people and organizations thousands of hours and dollars, and that makes this path of programming all worth it.

Want to be notified when a new post goes live?

Thanks for reading! If you have any thoughts, questions, or anything else please reach out. I always enjoy hearing from people.