Everybody knows time is money, but it seems to be a very important concept that seems to escape a lot of developers’ mind as we strive towards code utopia. One of the strengths of developers as Larry Wall, the father of Perl, has put it, is laziness. We’re willing to go through great distances to save time in the long run. We invest into infrastructure so that we can benefit from it in the future. This causes us to obsess over frameworks, languages, plugins, coding standards, documentation, and so on.
One key thing to remember as a programmer is: “time is money”. The ultimate law of an employee is that you must bring in, in one form or another, more money than you cost. If that’s not the case, the company can quickly go out of business, or you become a burden on the resources and less of an asset. Sometimes, as a developer, we need to take a step back, and think “What does business what? What does business need? What WILL they need? How are the investments I’m making going to further that?” Often times, the code infrastructure investment doesn’t.
From the business standpoint, “We just lost a month worth of development time, and ALL these bugs just came out of nowhere! Our competitors just launched X! We need to gain ground!”
As developers, we need to understand that we’re playing a support role, a significant support role, but a support role nonetheless. We need to be more of an asset and less of a liability. We’re helping to keep a ship sailing. When we make our time investments we need to not only make it from our the perspective of making developers lives easier, but also whether or not that type of investment is even an option for the business. As a developer we are often times protected against all the business craziness so we can focus on our work, but at the same time, I do believe that exposure to such business requirements can help us better align how we use our time a bit more appropriately. At the end of the day, if the ship sinks, what good are all those technology investments we made?