Taking Risks while Developing Code
As the coding geek behind Custom Visuals, I’m responsible for the application development that takes place under this roof. About half of my livelihood since 1984 has been as a small business application developer and the other half as a software engineer in larger corporations. They both have advantages and disadvantages, and I have no reason to, or intention of, putting down either one. There is one big difference that has always stood out to me and I’ve commented on it with friends and colleagues a few times in the last decade or two.
In the corporate environments I’ve worked in, there is a premium for churning out predictable code to solve problems in acceptable ways using the tools provided. Straying from the preferred path in the corporate environment is not encouraged, which leads to a familiar looking code base, but also higher levels of technical stagnation. Bringing new ways of solving problems, connecting to databases, accessing websites or even changing the logging approach to something that allows easier troubleshooting means that your code sticks out like a sore thumb since it is different from the rest of the company standards. The upside of sticking with the standards is that is anyone in your immediate group, or perhaps throughout the entire organization, can more quickly follow and understand your code and make any necessary changes.
As one of the founders of Custom Visuals, I have a much higher amount of freedom to explore areas that are not placed directly in front of me. Taking the programming language Perl as an example, I can decide to update to a newer version of a CPAN module without worrying how it will affect groups that are not part of my immediate circle. By running a few tests or if I have something in my ever-growing test suite that exercises the new module, I can test and deploy the module in a matter of minutes. This helps to keep the code base modern and remove some of the cruft that inevitably creeps into projects over time.
In the larger scheme, this means I can evaluate entirely new concepts, libraries, languages, technologies, etc. and decide whether it makes it into the project or not. It also means my experience and knowledge of new areas grows, as well. While working on projects within Custom Visuals, I may take more time to explore a new concept before figuring out how to steer a project into what I already know how to use. In the short run, this likely means a single project takes a little longer to develop while some additional learning and experimenting takes place. In the longer run, this means projects have more tools available to make development quicker and more flexible.
From a broader perspective, I have found a nice balance of technical learning and basic implementation in both environments. There is always something to learn in both and there is also a chance that you will stray into the wilderness while implementing a new idea. Knowing when and how to implement new ideas is based on experience.