Principals from Programming

Following is a list of principals I’ve picked up, during my programming career, that I hope to carry in everything I do.

  • I am an idiot. That has profoundly affected the way I code. Everything must be simple enough
    for a child to understand, and even then I struggle. Being an idiot has forced me to refactor
    mercilessly. If I don’t, there’s no chance of me understanding my code. And if I don’t understand
    my code, there’s no chance of me getting it to work.

    I’ve seen people who can solve complex problems, and I admire them. Alas, I’m not one of them.
    So whenever I have to solve a complex problem, I make it simple first.

    If I can’t make a problem simple, it’s usually because someone else insists that it remain
    complex. In that case, I have to wait for someone smart to fix it (thank you, smart person),
    or for someone to change their mind and allow me to make the problem simple. Wayne Conrad

    Complex problems are just a series of simpler problems smushed together.

  • The most powerful programmers are the ones who came to the computer with a problem to solve. The least powerful are the ones with something to prove, about themselves or the unique rightness of their way of thinking. That’s arrogance.
    A curious and motivated user with the right tools is unstoppable, except when it comes time to work together. Then a single stinker, a person who wants to stop progress, has a lot of power, if we give it to them. Dave Winer, 2001

    Solve problems, don’t just point them out.

  • The ideas I stand for are not mine. I borrowed them from Socrates. I swiped them from Chesterfield. I stole them
    from Jesus. And I put them in a book. If you don’t like their rules, whose would you use? Dale Carnegie

    Steal ideas liberally from everyone else. Originality is not a virtue. Learn from the past.

  • The danger of our culture.- We belong to a period of which the culture is in danger of being destroyed by the
    appliances of culture. Nietzsche

    Put trust in people, not in things.

  • A culture can not survive if it attempts to be exclusive. Pope John Paul II – Quoting Gandhi in India, November 1999

    Don’t build solutions that try to do everything. Nothing can do it all. Instead, create solutions
    that play nicely with others, do only a few things, and do them well.

  • We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all
    evil. Donald Knuth

  • More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other
    single reason – including blind stupidity. W.A. Wulf

    Perfectionism can be taken too far. It’s best to get a solution that does most of what you want to do then none
    at all. Using a war metaphor – it is better to win the majority of small battles then to wait for one conclusive
    battle-to-end-all-battles.

  • The Seven Habits: Be Proactive

    It is best to actively hunt for solutions to problems and not have problems come hunting for you.

  • The Seven Habits: Begin With The End In Mind

    Projects must have solid deliverables. Only when goals are can be stated in clear cut terms can they be
    achieved. Projects chasing after goals that are not black and white are never successful.

  • The Seven Habits: Put First Things First

    Sometimes you need to do the things that failures do not like to do. Every journey begins with that first
    step. And sometimes it is the hardest. Schedule your priorities, not the other way around.

  • The Seven Habits: Think Win/Win

    Aways shoot for everyone looking good in the end. Find the good-guys and make sure they each share in
    any success. If you can do this with your enemies – then you’ve really done a great thing.

  • The Seven Habits: Think First To Understand, Then Be Understood

    Business projects that aren’t solutions to diagnosed needs are wasteful projects. They are doomed to
    failure. Especially true in technology. While technology may expose new capabilities – it is more typically
    true that it is business need that should be satisfied by technology – not the other way around.

  • The Seven Habits: Synergize

    All of the parts to a solution should cooperate with each other and play nicely with each other by being designed with inputs and outputs that are simple and conscise.

  • The Seven Habits: Sharpen The Saw

    Continuously improve skills and knowledge by seeing what others are doing in the world.

    Update: This piece was republished in SOAWorld 10-19-2008.