Comments on: How to be a better programmer http://richardkmiller.com/212/how-to-be-a-better-programmer Wed, 08 Feb 2012 16:07:14 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Paul http://richardkmiller.com/212/how-to-be-a-better-programmer/comment-page-1#comment-13155 Paul Thu, 23 Nov 2006 04:07:12 +0000 http://www.richardkmiller.com/blog/archives/2006/09/how-to-be-a-better-programmer#comment-13155 Derek, While I can appreciate the logistical noodling you have done to deconstruct what I wrote. You missed the point by a very wide margin. Each of these maxims are true on their face, but just like Poor Richard's Almanac, if you tried to live by every word in every situation, you'd fail miserably. They are meant to be applied as needed. And yes, it is an art form first, with a technical basis. One could make the argument successfully, that either music or oil paintings are simply a confluence of mathematical criteria that satisfy some golden mean - and they'd be right. But, only the master of that medium can create that golden mean at will (talent) - irrespective of the educated man who comprehends the mechanics. ...Paul Derek,

While I can appreciate the logistical noodling you have done to deconstruct what I wrote. You missed the point by a very wide margin.

Each of these maxims are true on their face, but just like Poor Richard’s Almanac, if you tried to live by every word in every situation, you’d fail miserably. They are meant to be applied as needed.

And yes, it is an art form first, with a technical basis. One could make the argument successfully, that either music or oil paintings are simply a confluence of mathematical criteria that satisfy some golden mean – and they’d be right. But, only the master of that medium can create that golden mean at will (talent) – irrespective of the educated man who comprehends the mechanics.

…Paul

]]> By: Derek http://richardkmiller.com/212/how-to-be-a-better-programmer/comment-page-1#comment-7296 Derek Thu, 14 Sep 2006 07:54:07 +0000 http://www.richardkmiller.com/blog/archives/2006/09/how-to-be-a-better-programmer#comment-7296 I would like to think that a better programmer writes better code, but I don't see how much of this advice addresses that concern. Thinking of #14 in particular, I see how this might be applied to being a better programmer, but not how to produce better code. While it's true that the more elegant solution is often the better one, the superiority of one algorithm over another is pretty objective in computing. A complexity analysis (big-O and the like) will usually answer the question of which solution is better. In the event that two solutions are similar in complexity, real world application would reveal which excels in performance and robustness. All those elements being equal, you can finally subjectively evaluate the solutions - making the artistic test the final one. What about the "art" of making code readable and maintainable? While these are valid concerns, a great programmer still wouldn't sacrifice significant performance for their sake. As for developing an individual style, I think that's fine for coding conventions and for those rare times when it really doesn't matter what type of loop you use and similar circumstances, but there are advantages to conformity. Maybe my style dictates that I use a selection sort whenever a sort is called for. It's a simple solution (#4 above), and maybe it's fun (#16) taking a bathroom break while waiting for your algorithm to run, but #8 definitely applies: there is a better way. And in comparison sorts, it doesn't get better than quicksort (because of the O(n log n) lower bound) so now #8 is out. I think it's fine to adopt that style and not insist on rolling your own just because writing code commando-style fits your style. While at the outset the author downplays the need for a mentor, some of the advice relies on using others for advancement. I think the state of the art in coding has moved far beyond this informal approach. Enough work has been done in computing that we can, with confidence, say that one solution is better than another. My impression from this advice is that we should stumble through trial and error of solutions forever, always hoping to find something better. And then when we do, we won't even know why it's better. But I suppose this is the heart of the debate between academic and practitioner. Personally, I'd rather know why I need the 'const' keyword, and not just use it because I know the compiler complains if I don't. I would like to think that a better programmer writes better code, but I don’t see how much of this advice addresses that concern. Thinking of #14 in particular, I see how this might be applied to being a better programmer, but not how to produce better code. While it’s true that the more elegant solution is often the better one, the superiority of one algorithm over another is pretty objective in computing. A complexity analysis (big-O and the like) will usually answer the question of which solution is better. In the event that two solutions are similar in complexity, real world application would reveal which excels in performance and robustness. All those elements being equal, you can finally subjectively evaluate the solutions – making the artistic test the final one.

What about the “art” of making code readable and maintainable? While these are valid concerns, a great programmer still wouldn’t sacrifice significant performance for their sake.

As for developing an individual style, I think that’s fine for coding conventions and for those rare times when it really doesn’t matter what type of loop you use and similar circumstances, but there are advantages to conformity. Maybe my style dictates that I use a selection sort whenever a sort is called for. It’s a simple solution (#4 above), and maybe it’s fun (#16) taking a bathroom break while waiting for your algorithm to run, but #8 definitely applies: there is a better way. And in comparison sorts, it doesn’t get better than quicksort (because of the O(n log n) lower bound) so now #8 is out. I think it’s fine to adopt that style and not insist on rolling your own just because writing code commando-style fits your style.

While at the outset the author downplays the need for a mentor, some of the advice relies on using others for advancement. I think the state of the art in coding has moved far beyond this informal approach. Enough work has been done in computing that we can, with confidence, say that one solution is better than another. My impression from this advice is that we should stumble through trial and error of solutions forever, always hoping to find something better. And then when we do, we won’t even know why it’s better.

But I suppose this is the heart of the debate between academic and practitioner. Personally, I’d rather know why I need the ‘const’ keyword, and not just use it because I know the compiler complains if I don’t.

]]>