As change goes by

Until about two months ago, my job was that of a programmer. That means: you have a very specific computer science like problem and you have to resolve it coding. Computer language code was, indeed, the answer to my work-related problems. From this point of view, then, the best way of increasing productivity was that of churning out code at ever growing levels of both speed and quality. It is what happens when you work at a company whose core business is to produce software.

I have been working at another company, whose core business is not software. For them software is just a mean to an end. That is, they have real life problems that might or might not be resolved by software. In this case then, the best way of being productive is to find out the exact problen and find the solution that best resolves it. Sometimes this solution is a one-man-month sized software development, another time it is a configuration twitch on the existing infrastructure, and yet another time it is a change on the way receipts or invoices are handled, a change of procedure.

This has an advantage and a disadvantage, for one, the perceived impact of solutions might be far better on the non-software business. That is, if three hours worth of coding resolve a huge problem and a month worth resolve none, then the three hours are the valuable part. I like this, it gives a lot more room for creativity and interesting implementations, and spending time where it is worth. This also means that purely IT based factors, like your Operating System, your programming language or your design patterns automatically become less important. If the thing works, then it is good. (It is of course up to the developer to build a good design, but only good enough for the tasks at hand).

So far I like this problem solving approach more than the software developing one because with the former coding is only put where is worth and a lot of other problrm solving tools can be used. It is not easy, but it sure makes things a lot more interesting