News, views, tips and tricks on Oracle and other fun stuff

7 Golden Rules That Make You a Better Programmer

Steven Feuerstein published a new presentation titled: Golden Rules for Developers [PDF].

Here is a summary of his seven “golden rules” that will help you write better code:

  1. Don’t repeat anything.
  2. Hide everything.
  3. Don’t take shortcuts.
  4. Embrace standards.
  5. Build on a foundation.
  6. Never lose information.
  7. Don’t write code alone.

Agreed with all. I would also add an eighth one: Understand your data.

What would you add?

Filed in Oracle, Tips on 10 Jun 10 | Tags:

Reader's Comments

  1. |

    Ah, data. Programmers don’t like data 🙂

    Yes, agree to all, but it’s also important to understand that #1 and #2 are directly contradictory – “in tension”, as the euphemism goes – and you have to choose between them on a case by case basis.

    • |

      Jaime, I cannot see how #1 and #2 are directly contradictory based on the explanation in Steven’s presentation.

      Oracle PL/SQL programmers must like data, otherwise maybe they should switch to some other programming language that is not database centric.

      On the other hand, I see your point that as programmers we are more interested in coding rather than data.

      • |

        Hey Eddie,

        The direct contradiction is that you if you want to reuse something you have to expose it. The price of reuse is lower encapsulation and higher coupling. In Steven’s example the tradeoff is a no-brainer, but if we’re going to extrapolate a general rule out of that we need to be aware that this is a careful balancing act. Sounds a bit pedantic, but I have seen many systems fall into this trap.

        For example, hard-coding the value of pi all over the place is a bit silly. Putting it into a constant in a header file is much better. But having our financials system hit a web service API on our LMS application to retrieve its value for pi is even sillier than hard-coding. So we’re better off accepting a bit of repetition and just defining our own pi.

        So, yes, these are excellent rules, but as is so often the case, their truth is not a simple truth.

        And yes, I totally endorse your rule #8. It never ceases to amaze me how many talented application developers go to pieces when confronted with a simple ETL problem. PL/SQL guys are no doubt much more in the groove, but general app developers need to be much more comfortable with data.

  2. |

    […] 2010 Steven Feuerstein lists seven excellent “Golden Rules” in his presentation (via Eddie Awad) and says “Don’t repeat anything. Aim for a Single Point of Definition for every […]

  3. |

    In addition to understanding the data, a good programmer needs to understand the users, the process, and the business.

  4. |

    As much as possible, avoid coding in PL/SQL.

    Never lose sight of the goal of the design.

    It’s difficult to get paid to program if you get fired.

    Sometimes the dumb way is the better way.

    It is extremely rare to have a system in isolation. Deal with it.

    Don’t fall for marketing fluff.

    Use the level of bleeding-edginess appropriate for the business.

    • |

      All good ones Joel. By “avoid coding in PL/SQL” I am guessing you mean: If you can do it in SQL avoid coding it in PL/SQL. Cheers!

      • |

        I’d say “avoid coding altogether”– or, at least, move to the most abstract/declarative/high-level language or tool you can and still be performant. Life is too short to wrestle with low-level details, unless there’s a very good reason.

        • |

          Eddie, yes, that’s what I meant, but it seemed more entertaining to put it that way given the post I was responding to. I highly recommend Steven for PL/SQL, by the way, but I have a problem with the implicit idea (which I am not saying Steven puts out, just that it is out there) that programming in PL/SQL is generally the best way to go. There is often a problem with people confusing PL with SQL, for that matter.

          Antonio, I have to say, there are a lot of very good reasons not to use “…the most abstract/declarative/high-level language or tool you can and still be performant.” A few that come to mind are: declarative may not be the best way to go (SQL itself was supposed to get rid of programmers, right?); available expertise may not be; performance may be overridden by maintainability, including the possibility that getting locked into a tool may diverge from Oracle’s direction (many examples of tools that were cool in the 90’s and suck now are out there); the marketing fluff I referred to, which may have many other names like paradigm-of-the-day; some tools don’t show that they suck until you scale up; some tools may simply be overwhelmed in the market by Oracle’s tools or other herding effects; some paradigms suck; and so on.