From the Inside: September/October 2013
Why do I still program?
I get asked that by various people several times a year: Why do you still program? Mainly this is at the Spectrum Conferences, but I do get it other times as well.
The easy answer, and one I always say with a smile, "Because I like doing it!" Well, that is not the only reason. I really do like programming, and the puzzles that are involved, but there is more to it than that.
As many of us get older and more experienced in application development, people expect you to give up practical programming and do more "noble" tasks such as managing a team of programmers or architecting systems; or in my case, take over a magazine.
While this is all important, it points to a model of management with which I'm not always in agreement. There are two management models that people usually chose from — Vertical and Horizontal.
Vertical management basically means that the people on top supervise other, cheaper employees. They spend all their time making sure the job gets done correctly and on time, attend meetings, and make design decisions. The major trap with this management style is sometimes the design decisions do not take into account how the cheaper developers decided to implement the "design," or how the upper management thinks the design was implemented, when it may have been done differently for practical reasons.
This model works well in large companies and gives you the ability to "scale up" quickly and easily.
Horizontal management means the top people are deeply involved with a lot of the work. This creates a major trap that I'm sure all of us know a lot about. It means we do so much of the work, that it is hard to pass projects on to cheaper developers because it would "just be easier and faster for me to do it." This model does not "scale up" well. Especially if you are a control freak and never want to let go of things.
I have a tendency to like the Horizontal management style, even with its major trap, because it means I'm more involved with how something is implemented, in addition to the why something is implemented. Many times the great ideas from "upper management" sound good on paper, but the practicality of implementing it means the project fails.
By doing some of the coding, then I understand these limitations better, since I have to implement the work within the same confines as the other developers that I'm asking to do the work.
The other reason I program is because, time and time again, I find that my "Grand, Solve All The Company's Problems" ideas, are not well defined. This causes design decisions to be placed on the other developers. While in some cases this is fine, in others they are missing a lot of background regarding why something should be done one way instead of another.
Programing and implementing some projects helps me find those places that are not already well defined, and in turn helps me define them.
Don't get me wrong, programming is time consuming, and it takes away from the management time. The trick is to find a good balance between architecting, project and people management, training, and programming. The management should come first; the programming comes second. But I feel that programming is still just as important as the management.
Located in Thorton CO.
View more articles