Let me start by admitting to an open secret: I still write code. If you are like many people whom I share this secret with, you’re probably thinking that’s a crazy thing to do. Well I’m not going to argue the point, after all the business folks talk at length about the role of a CEO and management, and believe me it does not include writing software. After all, Kitware’s developers run circles around me in terms of coding speed and mastery of the software process, they are certainly more cost effective, and have the advantage that they can stay focused on a single project while I am interrupted continuously throughout the day. So why the heck do I still write code?
There are selfish reasons certainly. The act of writing software is a creative process involving both sides of the brain, with the feeling at times akin to sculpting or fine craftsmanship, combined with the abstract beauty of mathematics. I also enjoy working alongside smart people with the give and take of creating cool new ideas and the challenge of making the right engineering trade offs. It is truly a gift to learn from a team of talented people for which I derive immense satisfaction. But as we all know a company does not succeed on selfish motivations. So in the final analysis, the act of writing code is ultimately an act of communication, enabling me (and the rest of the management team most of whom also write code) to better understand the needs, talents, challenges, and opportunities that emerging software technology offers.
A prime example is our recent transition from centralized version control systems like SVN and CVS to the distributed system git. Anybody who knows anything about these systems understands that they introduce profound impacts to the software process, and to the way in which we collaborate within the Company and with our collaborators and customers. I believe that as a manager it is essential to actually try to use git so that I can better understand the associated issues. It also enables me as a relatively naive outsider to directly recognize the pitfalls that other novices like me are likely to run into, and to press developers for simple solutions that allow the broader community to engage with the process of technology transition. (We all know that developers occasionally become so enamored with technology that they forget to communicate about it, making it relatively inaccessible to anyone but the experts. Occasionally it’s necessary to push back on this tendency.) In the case of git, there are also other profound organizational implications due to distributed workflow, which may mean possibly adjusting the way we work at Kitware, as well as the way we collaborate with our customers. While I certainly will never be an expert in this area, having some rudimentary knowledge and being able to communicate at a high level about concepts is invaluable.
As managers, it is our job to ensure that we provide effective business solutions to our customers; ultimately this is what makes a business succeed. In turn this requires that we provide the necessary resources to our developers and support staff to ensure successful, efficient execution. This demands continuous communication and a nuanced sense of what the key issues are in an organization. And for me one of the best ways to achieve this is to do what our developers do: write some code.