About Me

In the software industry, more often than not, projects face difficulties pulling things together and delivering what the market expects within the budget and time expectations. The vast majority of the time, these problems have more to do with communication within the team (business people are part of the team too) than with any technical issues. Therefore, as the person who often jumps in and drives troubled projects to completion, I spend a lot of my time being a therapist / psychologist to help the group get past their road blocks. I have learned over the years to always look for the root causes and focus my efforts there. Accomplishing this requires a skill set beyond knowledge of technology. Some of the most important work that I do is spent mentoring, keeping people communicating, setting the example, and enforcing consistency. All of that being said, when things are truly hopeless, I will be the first person to let the product owner know when it is time to cut their losses and start over or abandon the things they are emotionally invested in. I truly believe that software engineering should be a career dedicated to constant, active learning. Therefore, learning new things and deepening my knowledge with technologies I already use is a passion of mine. I find people in our field that abandon learning to be stale and uninteresting. So, when I work with someone like this, I try hard to bring them up to speed and inspire them. I have spent most of my career writing C# web applications. However, more recently, I have developed a deep love for all things JavaScript. I am also developing an appreciation for Python, and to a lesser extent, Ruby as of late. In my spare time, other than spending time with my wife and two sons, I love all things astronomy, playing with Arduinos and Raspberry Pis, and running.

About This Blog

This blog is primarily dedicated to mentoring and having something to refer to. It is also for taking notes as I learn new things. Hopefully, over time, it yields some original thoughts. But, for the purpose of mentoring, that is not necessarily a requirement. Another focus is to have conventions documented and ready to use on any new project. Over the years, I have grown to dislike governance because it is often developed and enforced for the wrong reasons. In the worst cases, it often leads to "the blame game." I have never witnessed governance being successful in practice because of this. However, teams need to work together and communicate. I find that having a preexisting framework of options that can be tweaked based on culture and team input starts the conversation and goes a long way to moving past "plumbing." This allows the conversation to move on in order to focus on value for the users and business that serves them. From time to time, team members will have legitimate arguments against what is contained in this blog. Other times, these conventions will be out of date. Whatever the case, people often just want to be heard. This blog is not intended to be an authority, but it is not beyond its possibilities.