in reply to brilliance or... easy erasure?

In my intro comp-sci classes years and years ago, my professor used to describe this as the difference between "hacking" and "software engineering". "Hacking" was the interative try/fail/fix cycle, driven more by intuition than by design. "Software engineering" was supposed to replace that by designing it right the first time so that debugging was errors in coding, not errors in design.

Ironically -- or maybe intentionally -- test-driven-development is just a structured (software engineering) approach to the "try/fail/fix" cycle:

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Replies are listed 'Best First'.
Re^2: brilliance or... easy erasure?
by samizdat (Vicar) on Sep 06, 2005 at 15:50 UTC
    Indeed. I have only ten credits of CS to my name, so I would definitely fall into the 'hacker' camp. This also speaks to the argument that's often raised of whether one should specialize in one language and learn it well or be adept at switching gears and contexts so that one can solve many problems using the tools at hand. Could I be better if I were more disciplined in my analysis? Perhaps so, but I wonder if I would have developed the abilities that I have to hold many levels of a problem in my mind at once.

    One could say that -- using my example -- a more disciplined, careful coder would not have made that mistake, and, thus, would have been ten minutes more productive. Yes, indeed, he would have. Could he even be tackling that task, though, if his experience was only in Perl and HTML?

    There are environments where expertise is important, and careful craftsmanship. Certainly, middle managers of big corporations like to hire such programmers. Certainly, CS professors are drawn from these ranks. However, who makes more money? The problem solver or the detail-freak? The entrepreneur or the academic?

    There's an interesting parallel that showed up at a conference I attended of professors of MBA schools. One of the more controversial, but well-documented, papers presented was a paper that examined the correlation between years of business school completed and business success. The paper embarrassed the heck out of the professors, of course, because it showed an inverse correlation. That is, the more years of business school completed, the less likely the sampled group was to be successful in business. :D

      To speak just your first muse: the more languages and ways of doing things you have learned, the better able to solve problems you are likely to be.

      Different languages have different strengths and weaknesses and tend to encourage using different techniques for solving problems. For example, in Perl we often reach for a regex (in one of it's many guises) or a hash to get the job done. Those tools provide a completely different way of thinking about problems than languages like C++ where hashes and regexs are way down the list. However, having used Perl somewhat, I now have a slightly different approach to writing C++, and I really miss modifiers!

      Bottom line: if you have the opportunity to learn a new language, do it - you will benefit from the effort.


      Perl is Huffman encoded by design.