About

As a technology enthusiast with interest in educational learning management systems, I’ve been working in the consulting field for the past 5 years. I graduated from The Pennsylvania State University’s School of Information Sciences and Technology.

While in school, I learned a lot about a lot of things. Being in IST was like getting half of an MBA degree and half of a computer science degree – we really did bridge the gap between the technical and business worlds. At the time, this sounded awesome. No one else was doing this (back then, at least). We were taught how to work with relational databases, code in Java, write PHP web applications, and then how to use these things to run an organization, manage people and change, gather requirements, work in a consulting environment, and write business proposals. As they told us back then, we’re already lined up to be middle management right out of school.

Then we started looking at job openings and realized that the world hadn’t caught up to us yet. Job postings were for programmers or functional analysts. Very rarely was there truly a role for us cross-functional IST grads (the notable exceptions being from the companies that the school was partnered with and recognized the value someone with our skillset could be). Many of my friends became pure developers, but had knowledge of how their code impacted the overall business. Others became full-scale business analysts performing test scripts and writing functional designs, but always with an understanding of the technology behind what they were working on.

I personally ended up in a large consulting company where I had the pleasure to really straddle the line between developers and business analysts. Of all places, it was in the system documentation team that I was able to use the business and user interaction knowledge I had to write in-depth documentation for an enterprise level loan originations system while also developing XML-based automated documentation using DocBook. Previously, things like the data model were documented by hand. The code changed much faster than a person could keep up with and the end result was often times out-dated documentation. Automating things like the data model, web services, workflow, and system configuration resulted in 100% accurate documentation that our clients loved.

Then I got to spend a year and a half traveling to Des Moines, IA. Working directly with clients really opened my eyes to what happens once the software leaves the product engineering group. All those times that people say “a client would never do this” during design reviews are times when you need to stop what you’re doing and remember “you are not your users.”  I spent much of my time on client site dealing with the shortfalls of our software doing things that “our clients would never want to do.”

I’ve tried as much as possible to bring those lessons from the client site back to the product engineering side when I returned.

And as for me personally, I recently found myself in the world of home brewing beer. It really opened my eyes to how good beer can be. I’ve always at least thought I liked “better” beers. Back in college, I stayed away from the frat beers and instead opted for the brew pub up the street. However, since learning more about making beer, I started to appreciate the subtleties.

Also, I’m becoming more interested in microcontrollers such as the Arduino. I like being able to apply the technical knowledge I have into something tangible in the real world. Even making a light blink because of a piece of code I wrote is satisfying. Coding for the web has a different type of satisfaction – it makes something accessible to others. Making that light blink (or sensor trip a relay, etc) makes it personal to me.

Anyway, this is a bit of insight into who I am. Feel free to contact me if you want to talk about anything.