Site News for 9/9/07 through 9/15/07How to be a Benevolent Dictator

Of Coders, Professional Programmers, Martial Arts and Ginger Cats

September 16th, 2007

Reggie, My Ginger CatDavid Blix at NetFX Harmonics posted this article, Coders and Professional Programmers, about a month ago and it came to my attention via DZone last week. I had posted a comment on his web site mildly critical of his point of view but he decided to moderate it out and not show it on his blog, as is his right, just as is it is mine to extend my comment into a blog post of my own.
.

The main part of his post that I disagreed with was his suggestion that to become what he calls a ‘professional programmer’ you have to engage in a bit of mental self-flagellation as he describes here:
.

At this same time I realized that I really, really wanted to be a professional programmer and not a coder in any way. So, I said goodbye to Visual Studio and took back my EditPlus to do all my .NET work. I was not about to rely on Intellisense to do my work for me and already knew the danger of learning a new technology by error messages. For the next year I deliberately did all my development without color syntax and without Intellisense. I’ve never had any respect for “drag-n-drop” property developers, so I never used the designers anyhow, but now I wasn’t even going to let Intellisense help me either.

And here’s my original comment:

I like some parts of what you had to say but I have to strongly disagree about not using the Visual Studio environment to code and not relying on online resources to assist you. To do so handicaps your ability to learn and produce.

I dealt with one contract ‘coder’ who insisted on doing things “the hard way”, using a text editor rather than the IDE and not using all available help resources like you described, and I had to let him go. The problem was that he was too slow as compared to the rest of the team and his code was often poor in comparison.

I agree that internalization is the goal but I don’t see punishing yourself as the way to achieve it. Doing so reminds me of the ginger cat in this martial arts parable: http://www.shotokai.com/ingles/legends/cats.html

David also seems to place great stock in tests, like the 70-536 (Microsoft .NET Framework 2.0—Application Development Foundation) test. It’s his opinion that one should not be a .NET developer unless they have memorized huge amounts of trivia. My disagreement here isn’t with learning about the Framework, one should. It is with cramming on a lot of trivia temporarily into ones brain with the mere goal of passing a test or two. This is what most people do and what is encouraged by this money making enterprise. The ability to pass a test and internalization of skills are two very different things.

As I said in my comment, his approach reminds of the ginger cat in the classic martial arts parable, The Cat’s Martial Arts Assembly. In this tale, told by Taisen Deshimaru, several cats tried to catch a particularly tough rat and failed while a wise old black cat caught the mouse with seemingly no effort. The cats meet to discuss with the old black cat why they couldn’t catch the mouse. You will want to read the whole thing to get the full context but here’s what was said about the ginger cat:

Then the ginger cat spoke: “I am enormously strong, I am constantly exercising my ki and my breathing through zazen. I live on vegetables and rice soup and that’s why I have so much energy. But I too was unable to overcome that rat. Why?”

The old black cat answered, “Your activity and energy are great indeed, but that rat was beyond your energy; you are weaker than that big rat. If you are attached to your ki, proud of it, it becomes like so much flab. Your ki is just a sudden surge, it cannot last, and all that is left is a furious cat. Your ki could be compared to water pouring from a faucet; but that of the rat is like a great geyser. That’s why the rat is stronger than you. Even if you have a strong ki, in reality it is weak because you have too much confidence in yourself.”

Ki in the context of discussing programming could be considered the internalization of skill as David mentioned. My point is that it is easy to become too attached to a specific skill or language and to become prideful and overconfident about it. There is also the problem of becoming prideful about how you learned it, ie “living on vegetables and rice soup”. Sooner or later a ‘rat’ of a project will come along and defeat you.

As anyone who’s programmed for a while knows, things change. If you spend a lot of time learning the trivia associated with .NET Framework 2.0 it will become useless to you in a few years time. You may find your career stagnant because you’ve become pigeonholed into being an useless expert in an old technology. Many expert level VB6 and FoxPro programmers have found themselves in this position.

However, if you learn how to program where you can easily adapt to any language you encounter you’ll usually do well. As Bruce Lee said, “Don’t get set into one form, adapt it and build your own, and let it grow, be like water. Empty your mind, be formless, shapeless — like water. Now you put water in a cup, it becomes the cup; You put water into a bottle it becomes the bottle; You put it into a teapot it becomes the teapot. Now, water can flow or it can crash. Be water, my friend.” When you’ve truly internalized programming as David suggested this is the state you’ll be in.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Entry Filed under: Personal Development


Rate This Article:

Not That GoodCould Be BetterOKGoodGreat (No Ratings Yet)
Loading ... Loading ...

6 Comments Add your own

  • 1. Andrejs  |  September 17th, 2007 at 9:47 am

    It is a nice response:)

    But I would like to add that I agree to both of you. The reason why I agree to David is: programming in text redactor while you are learning to program can help you very much. With this approach you can learn ins and outs, and know the language by heart.

    On the other hand, the reason why I agree to you is, that you need to learn programming not the language.

    I could say that I am Java programmer, but I could do programming in C# with a manual and API documentation but I would be dead slow…

    You need to be and know a little from both :)

    P.S. Excuse me for my English

  • 2. jfrankcarr  |  September 17th, 2007 at 11:22 am

    Thanks Andrejs

    My thinking is to use all of the tools and resources available, especially if you’re a working professional. Today’s IDEs make it easy for anyone with decent programming skills and experience to pick up a new language and be productive in it quickly. I don’t consider them crutches but very useful tools for rapid discovery. Unless one wants to be a “language lawyer” in a particular language there really isn’t a need to learn every nuance of it by heart since massive amounts of reference material is instantly available at your fingertips.

    Learning ‘the hard way’ is OK for an absolute beginner in an academic environment studying the basics but, if one is out in the real world you hopefully have already learned these lessons. Maybe that’s what David was getting at, that he’s met people who didn’t learn these lessons the first time around. I agree with him on that point, if that’s the case. If one doesn’t have the fundamentals down they won’t be an effective programmer.

  • 3. Arnon Rotem-Gal-Oz  |  September 17th, 2007 at 5:50 pm

    I think that the problem of mastering and memorizing the language is moot - since you can solve the same problem by accepting a mindset that assumes that anything which is not your core logic already exists either on the platform (.NET, J2EE app server) or on other libraries (3rd party controls, Open source projects etc) and then spend the few minutes needed to search it over (the first time or so). When you’d see the same problem again you’d already know

    What you get by memorizing is that you slow yourself as you learn, and then you may become a little faster - the problem is you’d be missing stuff you didn’t learn (things created by others which are not part of the platform). not to mention that at the end of the day it isn’t really about lines of code. It is about working, maintainable and tested lines of code which really factor out the time saves on initial coding

    Arnon

  • 4. jfrankcarr  |  September 17th, 2007 at 6:49 pm

    Thanks Arnon

    I agree that memorization does have its place. What I don’t like to see is the encouraged cramming with the goal of passing a few tests to get a certification. (This problem extends beyond just programmer certification and well into the general educational system but that’s for another time on a different blog.) I don’t think that most people retain a significant amount of this knowledge much beyond the testing period nor, given the degree of change, does it remain current and valuable for more than a few years if they do retain it.

  • 5. OJ  |  September 18th, 2007 at 12:11 am

    What I liked about the original post was the implication of a desire to be able to do your job (almost) regardless of the tools you do and don’t have at your dispoal. I also liked the desire to understand what goes on behind the scenes, and to learn as much as possible about the field.

    What I like about your response is that you indicate that use of such high level tools doesn’t make you less of a developer, and that the use of the right tool for the job is what a good developer should be able to do.

  • 6. jfrankcarr  |  September 18th, 2007 at 8:26 am

    Thanks for your response OJ

    Perhaps part of why I don’t like doing programming the “hard way” is that is the way I learned back in the 80’s when there weren’t any fancy IDEs. Of course, I highly customized my text editor to make my work easier. If you’ve ever read Robert Heinlein’s short story The Tale of the Man Who Was Too Lazy to Fail in his book Time Enough for Love you’ll find part of my philosophy in it.

Leave a Comment

Required

Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed


Most Popular Articles

Highest Rated Articles

Categories

Most Recent Articles

Feeds

 Subscribe in a reader

To subscribe by e-mail
Enter your address here

Delivered by FeedBurner

VB Opportunities

Archives