Yes I Still Write Code
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.
To write good code you must dedicate to that. You need to focus on what you are doing. I am not very sure of the quality of your code, but I would like you to think about that. In the company I work for, our CEO write code as well, but we pray everyday asking him to dedicate to bussness matter and don’t write any other line of code. Perhaps that is not your case, but I would like you to think about if you are helping software engineering with your code, or just the opposite.
If you like to code, alright, do your our project in your spare time, but keep in mind that to write good code you can not be interrupted again and again because at the end, some of your software engineers is going to suffer your bad code.
Coding is not easy.. and coding is not about if you uses a centralized or distributed control version system. It is much more, in the same way that writing object oriented software is much more that putting code in classes.
I hope it is not your case, but please, be sure or this.
To write good code you must dedicate to that. You need to focus on what you are doing. I am not very sure of the quality of your code, but I would like you to think about that. In the company I work for, our CEO write code as well, but we pray everyday asking him to dedicate to bussness matter and don’t write any other line of code. Perhaps that is not your case, but I would like you to think about if you are helping software engineering with your code, or just the opposite.
If you like to code, alright, do your our project in your spare time, but keep in mind that to write good code you can not be interrupted again and again because at the end, some of your software engineers is going to suffer your bad code.
Coding is not easy.. and coding is not about if you uses a centralized or distributed control version system. It is much more, in the same way that writing object oriented software is much more that putting code in classes.
I hope it is not your case, but please, be sure or this.
Zemog- Thanks for the comments, you make very good points. In my case I’ve been around a long time and written hundreds of thousands of lines of code in VTK and similar systems. I’m pretty good at algorithmic development having been trained with a PhD in computational sciences, so I can and still contribute. However the point of the article is this: writing code is about communication and staying connected with the development team. I’ve been in, and worked with, large organizations where the managers are disconnected from the technology. Believe me, these situations are not a good environment for technical innovation, since clueless managers can end up making poor decisions based on business measures alone. An agile technology company has to have decision makers who understand technology opportunities and risks, as well as the needs of the folks doing the work. This requires a concerted effort at communication, which is hard work. In my case, being a software person one of the best way to communicate is to periodically immerse myself in the world of the developers. Yes, at times I’m sure it strains the patience excellent developers such as yourself, but let me say it bluntly: communication is absolutely vital to the health of an organization, is hard work, and requires effort in both directions: from management and the talent. This is one reason why Kitware is such a great place IMO, management is very connected to the work at hand.
Must be good working with people like you. I am looking for such great place to work since I left the University but unfortunately, there are not such companies in where I live, and it is hard to me to move there. (married with two little childrens 😉 ).
I have played with ITK with one project in my University (www.uma.es) and I must admit it is really impressived the way in how that software have been done.
Thanks for your response.
Must be good working with people like you. I am looking for such great place to work since I left the University but unfortunately, there are not such companies in where I live, and it is hard to me to move there. (married with two little childrens 😉 ).
I have played with ITK with one project in my University (www.uma.es) and I must admit it is really impressived the way in how that software have been done.
Thanks for your response.
Zemog – We have a EU office in Lyon, France. Feel free to pay a visit sometime.