I consider myself a nuts and bolts developer. At the same time, I often comment I’m platform agnostic, which means as long as the tools at hand are sufficient to meet the customer’s needs I don’t really care what language or platform is used to provide a solution that meets the customer’s needs. I don’t need to invent something new, my goal is to write some nice, clean, maintainable code that helps the customer.

I meet a lot of programmers who are obsessed with writing really cool, clever code. They want to use the latest and greatest technology or tool and often want to create their own tools or technologies. That kind of innovation and passion for programming is how technology advances and I think that’s great. I was in midst of that environment during the 90s and the meteoric rise of web development many people call the dot com boom.

When I started coding I was one of those eager coders wanting to learn and use the latest technologies. As I moved from project to project and company to company, I occasionally found myself working with programmers who were more interested in their cool coding structures, platforms and development tools than they were trying to provide a cost effective solution to the person paying the bills. It was frustrating watching someone on my team spending weeks writing a really clever piece of code that went way beyond the requirements of the project while the project ran over budget and past the deadline.

I started off my computer career supporting end users. I think that’s why I found my niche in small to medium sized projects where I interacted directly with the customer and felt like I had a huge stake in a positive outcome for the customer. I learned how important it is to dig in and really understand their workflow and then utilize a database and user interface to make that workflow more efficient. That’s also true in reporting projects when the customer is really using the reports and visualizations you have produced. As these projects turned into long term support projects the ability to maintain them over time became critical and is an important part of my strategy in all phases of development.

Bottom line: Coding for the sake of coding doesn’t pay the bills for most programmers and it doesn’t fit into a customer’s budget. I am glad to reap the benefits of other coders pushing the technology; but I’m also more than happy to utilize boring but proven technologies to build my databases, user interfaces, data integration processes and visualizations.