views:

6996

answers:

94

I always liked to ask myself "what's the first principle(s) of this?" after I learned the basic stuff of something (e.g. programming). It's an inspiring question, IMO, that can force you to think about the most important principle(s) behind something, especially a skill such as programming.

So, what do you think is the first principle(s) of programming? I'll give my answer below a little later.

A: 

No infinite loops.

Mostlyharmless
And if you are a video game programmer?
Ed Swangren
Even video game loops have to terminate sometime. (I dont know, im not one)Also, programming is sort of like playing a guitar. Once you are 1337 enough (which you would be if you were a game dev), ignore the basics and let the instincts talk.
Mostlyharmless
The guitar metaphor is way off the track, IMO :P
pongba
What I'm saying is, that its easy for a good programmer to go back and selectively use his "lessons" as applicable. But once you tell a newborn that its okay to have infinite loops "sometimes", (s)he will think every situation falls in that 1% where infinite loops are allowed.
Mostlyharmless
@Mostlyharmless well, even "Infinite loops" will terminate some time too (Infinite time is just not real in this case). Even though I agree that inifinite loops is something to watch out for I hardly think it could be considered even close to "the 1st principle of programming"
kigurai
@kigurai: I was nowhere close to being serious when I gave that answer. Though it IS a common trap, its hardly a guiding principle. Its like saying "Dont drive the car off the cliff" should be the first principle of driving.
Mostlyharmless
@Mostlyharmless: And as such the answer got voted down ;)
kigurai
@kirugai: lol, i expected it to get a few down votes (okay as long as it makes some tired programmer smile)... what i did not expect was for it to get three up votes.
Mostlyharmless
+17  A: 

KISS (keep it simple, stupid).

It does indeed beg the question "How do you define simple?" And also "When is something too simple for the task at hand?" This is why you cannot become a good programmer just by knowing the first principle of programming.

Dima
I think this is a too general rule. It begs the question "how do you define 'simple', really".
pongba
and if you're stupid, how would you know if it was simple?
Steven A. Lowe
That's a good one, Steven :)
pongba
"This is why you cannot become a good programmer just by knowing the first principle of programming" - love it.
yuval
no, this is why you cannot become a good programmer if you're stupid. Intelligent people recognize simplicity. Read 'Zen and the art of motorcycle maintenance', where the author calls this 'Quality', and treats it as undefinable.
Adriano Varoli Piazza
The simplest solution is usually the best!
Martin
@Adriano Sorry, but Robert Pirsig's Quality is more than just simplicity.
Dima
@Dima: you're right, I mean that quality and simplicity (in this case at least) are both undefinable, yet we know it when we see it, if our eyes are trained.
Adriano Varoli Piazza
+35  A: 

Write code like if it was you that would have to maintain that code.

Daok
This is a very practical heuristics, 3x :)
pongba
Write code as if an axe-wielding psycopath will have to maintain it. FTFY.
Forgotten Semicolon
...and the axe-wielding psychopath knows where you live.
CAD bloke
..,and he has just sharpened his axe...
Roalt
dude, I love these comments, vivid and horrifying
CMinus
... and he is working by your side.
yelinna
... and you hear him muttering 'soon, precious, soon'
Adriano Varoli Piazza
+1  A: 

Sequence, Choice, Repetition

Joel Coehoorn
Sequence, Selection, Iteration
camh
Sequence, Selection, Recursion - or assignment, test, branch
Steven A. Lowe
+86  A: 
  1. KISS - Keep It Simple Stupid
  2. DRY - Don't Repeat Yourself
  3. YAGNI - You ain't gonna need it
Bill
KISS should be Keep It Simple Smart.The first time you have to rewrite a large chunk of your code because you didn't design smart and extensible you will agree to this. :)
Sandor Davidhazi
I think KISS should be "Keep It Simple, Stupid!"
Dennis Cheung
I'm actually working on a blog post about how these two are the two most near and dear to a programmers heart and how at the same time they are a bit of oxymorons as often times you'll need to choose one against the other
Andrew G. Johnson
I would also add YAGNI.
Daniel Straight
This enumeration is the wrong way around. DRY should be first.
Svante
I also like the "Keep it SUPER simple" expansion of the acronym.
Agos
@Agos: But that's not the idea. It shouldn't be super simple. It should be simple enough ;)
ya23
KISS and KISS again ;-)
Perica Zivkovic
I always the KISS acronym was kind of dumb and hypocritical. After all, the extra S is more than the phrase needs. Keep It Simple conveys the point. The Stupid, Super, or whatever is superfluous. But hey, has to be clever right?
Programmin Tool
@Programmin Tool - I don't think "stupid" is superfluous. I think it conveys that we have a tendency to want to be "smart" and this manifests as unneeded complexity. As I see it, the "stupid" tries to remind us of this tendency by helping us remember what we initially think is "smart" is usually not.
codekaizen
They are worthless if you don't understand the problem first: http://bit.ly/XwvOh
OscarRyz
A: 

Do not overuse Interface.

Pokus
How do you define "overuse"? I think the more appropriate way to say this is "Be aware of the possibility of overusing language features such as interface".
pongba
This one is too language-specific
finnw
+23  A: 

Be as lazy as possible.

OedipusPrime
Again, too general, IMO. This begs the question "How lazy is the appropriate amount of laziness, really?", because obviously "sloppy" is something you don't want to be either.
pongba
This is a reference to perl's "Laziness, Impatience, and Hubris"
Ólafur Waage
So we're talking about different kind of laziness? I thought by "lazy" Bob means "don't bother organizing your code before it gets tangled" :D
pongba
I think of programming laziness as "if the computer can do the job for you, it should". DRY and YAGNI are special cases of this principle.It can also be extended to "code clearly and plainly". When you come back to maintain the code the laziness should continue.
Darron
I've always said that there's an important element of laziness in programming... the "if the computer can do the job" type of laziness. This also becomes spending hours programming something to do a few minutes of work. Of course, the next time that few minutes of work comes along...
John Mo
Too general. By that analogy all variables and functions would be 1 letter because I was 'too lazy' to type out something meaningful. Assuming I had to maintain it also however, then perhaps you are correct, because I would make it as easily maintainable as possible.
Kyle B.
@Kyle: Yeah, that's the point. "True laziness" is making things easiest for yourself now as well as in the future. Which turns out to be the same as doing things properly. If you do less work now but more work later, you're not being "as lazy as possible" :)
Adam Bellaire
"I could write a good program that would handle this problem, but I'm really too lazy. I'll just suffer without."
Beska
+15  A: 

Do not reinvent the wheel.

Daok
The right answer to the question as to whether or not one should reinvent the wheel is always "it depends". So "don't reinvent the wheel" only goes so far. It may serve as a good heuristics most of the time, but not every time.
pongba
Some "wheels" need to be reinvented.
CrashCodes
Tell that to Dunlop. He invented the pneumatic tire. If it wasn't for him, reinventing the wheel, we'd have a pretty bumpy ride.
Kibbee
How about: Only reinvent the wheel if the benefits will be worth the costs
e.James
+3  A: 

Program with an audience in mind. By that, don't assume that anything you write will not be read and maintained by you or someone else.

A corollary to that: Prove that you understand the problem you are trying to solve by naming your variables and functions and classes well!

torial
A: 

Sequencing, what do I do and When do I do it.

Jim C
A: 

Refactor before it's too late.

Pokus
You don't wanna refactor too early, either. So that begs the question of WHEN.
pongba
When it needs to be done. :D
Jeff Yates
+1  A: 

Any problem can be solved with another layer of indirection.

Joshua
Actually, having too many indirections is itself an issue waiting to be identified and resolved. So..
pongba
resolved... by another layer of indirection! =)
Erik Forbes
Oddly enough, its true. Look at Spring...
Joshua
A: 
  1. Don't do it.
  2. If not doing it isn't possible, get someone else to do it.
Giao
A: 
0 + 1 = 1
1 + 1 = 10
10 + 1 = 11
11 + 1 = 100
100 + 1 = 101
101 + 1 = 110

Get it?

dacracot
Can't vote down right now. But will do :D
pongba
Don't like my humor? Ok, but it is a real answer. The "founding fathers" of programming coded in binary. The first principle of programming is binary. Its all based on binary. Get it?
dacracot
We don't need to get it anymore. That's why they invented assembly, C, C++ and all the other high level languages. Binary can take a hike. ;)
Jeff Yates
There's no practical gain in knowing that, because it's too basic and simple to be constructive in any scenario. And because everybody knows it.
pongba
Oh really! Tell that to the engineers at Intel who created a math error... http://query.nytimes.com/gst/fullpage.html?res=9C01EEDF1439F935A35751C1A962958260
dacracot
Problem is, the reason they screwed up wasn't because they didn't know binary arithmetic, so..
pongba
I suppose you speak Latin too?
CAD bloke
I agree that this isn't a great answer, but -5!? I find that an understanding the underlying machine does tend to make one a better programmer. Of course, that doesn't mean that we should program in raw 1's and 0's.
Steve S
+3  A: 

Know your tools.

dmckee
A: 

In general: Problem solving.

That is what it all boils down to.

Geoffrey Chetwood
And what's the 1st principle(s) of Problem Solving, again?
pongba
That's what everything boils down to. So if you think about it, we don't gain anything from this perspective.
pongba
@pongba: So it is an answer as useless as the question then? Perfect.
Geoffrey Chetwood
I don't think the question is useless, especially judging by the cute answers :)
pongba
+2  A: 

I got into programming by way of studying digital electronics, so I guess for me the basic logic gates (not, and, or, xor, implies) were the first principles of programming.

Bill the Lizard
+1  A: 

This is a good question.

  • Know your requirements
  • Know your user
  • Know your limits
  • Always assume you don't know everything
  • Always understand the code you're using/writing
  • Never reach conclusions without evidence
Jeff Yates
6 first principles. Any pithy summary?
S.Lott
A: 

Think as if you don't know any particular programming languages (so that you don't fall into the trap of "thinking in XXX". Code to realize that thinking using the proper language.

pongba
Actually I consider this to be not very helpful because "thinking in XXX" is a must to get to efficient, maintainable solutions. But I definitely encurage knowing several languages well, also several programming paradigmas, to avoid seeing every problem just from the point of a language.
mh
+9  A: 

Knowing when not to program.

ctrlShiftBryan
what on earth is this supposed to mean?
anbanm
And when is that?
pongba
Sometimes you need to tackle a users problem differently - not just code a solution.
RichH
Human judgement and decision-making are part of everything; sometimes there's no point in trying to automate judgement.
S.Lott
Sometimes the "problem" you're trying to solve by coding is caused by another problem that can be resolved without coding.
Christopher Mahan
absolutely - I often find as a consultant many programming problems are really people problems or process problems.
Booji Boy
What he means is that many programming problems can be solved cheaper and more timely by purchasing off the shelf applications, components, or libraries.
Gordon Bell
+2  A: 

When refactoring unnecessarily complex code, I often repeat the mantra:

The computer wants to do the right thing, you just need to get out of the way.

James Curran
Could you elaborate a little?
pongba
Much code, particular that by junior programmers, tends to be overly complicated. Most refactoring is just simplifying the code.
James Curran
+2  A: 

Principle: Software is Knowledge Capture.

Consequences: Many techniques for knowledge representation, all founded on Abstraction. Gives us layers, tiers, encapsulation, separation of concerns.

Many techniques for procedure representation, all founded on Sequence, Choice, Repetition.

S.Lott
+1  A: 

While keeping it simple (KISS) and not duplicating code (DRY):

  • Make it work right
  • Make it work fast
sharvell
Correctness is vital. But fastness isn't necessity.
pongba
A: 

Progamming is not for the lonely geek.

pmlarocque
+4  A: 

Programming is a means not an end. Or perhaps, "Can does not mean should."

CrashCodes
+1  A: 

Never completely believe what you are told about how the program will be used.

Will M
I assume you mean "... about how the program will be used?" - And Amen to that.
CrashCodes
Oops. Thanks. Many times I've been told, "no you don't have to worry about that edge case." Guess what?
Will M
+6  A: 

Coffee in, code out.

Tea in in my case =)
Clox
+2  A: 

It's all about the user.

Bryan Oakley
+20  A: 

Zen, part I: Programming is only the road, not the way.

Programming is only the technique to teach a computer what it's gotta do. To be successful in creating fast, reliable software means to know your algorithms, best-practices and all the other stuff not necessarily connected to your Programming (language).

Zen, part II: If you are in a hurry, stroll along slowly. If you really are in a hurry, make a detour.

Sounds silly, but do not let yourself get into compromises that (really) may trouble you afterwards. I got a rule: If you are at the core of a program, try to be as precise and good as possible. If you are using methods from the core that are deep in your software, try to be faster in coding. If you are coding above these two, you can even get a little bit more sloppy.

Design errors are the hardest to find and/or fix, next step are programming errors in parts everyone relies on, then the "real showing-off software parts". If you need to fix a design error at the end of a project, ummm, that's not good... ;-)

Zen, part III: Know your path, Neo.

Know your environment, tools and the stuff you rely on on a daily basis and get it sorted so that it works for you. Best if you use your programming "environment" so natural that you do not even have to think of it. If you have to get a job done do not introduce "fancy new stuff" but do your work. This stuff can be introduced in a new project, namely then when you have time to prepare and use it.

Georgi
Uh, and then again: I landed in Zen land whilst speaking about programming :)
Georgi
@part III - don't add "fancy new stuff" unless you're getting paid to do it!
Jason
+1  A: 

In practice, and very unfortunately, good testing turns out to be more important than good programming. Testing increases the value of ugly code. If you can't write beautiful code, you should at least make it testable.

Ates Goral
A: 

Structured Programming

Joshua
+15  A: 

Understand the problem first!

OscarRyz
Ah, finally somebody with this one. You ca kiss, yagni, dry all you want. It's useless if you program something for nothing.
e-satis
@e-satis: Yeap, that what I thought when I first answer this. I scroll for all the answer and surprisingly nobody posted before.
OscarRyz
Good answer. Hours and hours get wasted when programmers don't properly understand the full requirements of a problem.
Steve Wortham
+4  A: 

it doesn't work till you showed it in a test

That's not true, I've written tons of code that works and isn't tested! :D
Gavin Miller
"I haven't tested it, I have only proved that it is correct" :)
Daniel Daranas
+2  A: 

Write code for the next guy.

Gabriel Isenberg
+4  A: 
  1. Distinguish between cause and effect (working with computers)

  2. Distinguish between fact and opinion (working with people)

  3. As simple as possible, but no simpler (design)

Michael Easter
+1  A: 

Garbage in - Garbage Out It doesn't matter how nice your user interface is if the data is bad.

HLGEM
A: 

When you assume, you make a YOU-KNOW-WHAT out of U and ME.

The golden rule, that one is. Always verify what you're taking for granted.

millenomi
I like this one.Don't just assume, especially not unconsciously.
pongba
+2  A: 

DRY, pretty much everything else spawns from it. KISS is the other end of the balancing act to make sure you don't pursue software elegance to levels of insanity.

Quibblesome
+1  A: 

Think about how then end product will be used at least as much about how the code looks. You could write the best commented, most maintainable, most brilliantly logical code ever but it's essentially a failure if no one wants to use the end product.

+1  A: 

Occam's Razor. Reduce the problem/task to its simplest form. Then - and only then - start coding. Don't put the cart before the horse. Requirements first. Sure, they may evolve but the core requirement will be the core of your code.

CAD bloke
+7  A: 

If it wasn't tested, it is broken.

Raz
I agree on that one
Clox
+5  A: 

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

-- Charles Antony Richard Hoare

Christian Vest Hansen
A: 

Don't repeat yourself!

Tobias
could you say that again?
Steven A. Lowe
Ironic that this is a repost of several previous answers.
Neil N
+16  A: 

Premature optimization is the root of all evil. -- Donald Knuth

Ryszard Szopa
Whether in implementation OR design.
Epsilon
+1  A: 

If the system won't work on paper then it won't work as a program. The reverse isn't always true, but a good computer system is usually based on a good paper system.

Booji Boy
+1  A: 

Start with the output and work backward.

A: 

I will go with an item that is too often neglected: check your I/O.

When you write a program/function/etc. make sure that the input/output is valid.

Martin Cote
+13  A: 

YAGNI - You Ain't Gonna Need It. The idea behind YAGNI is to program for your requirements, not for prospective, potential features. The premise is that by keeping to what you need to program, you will (among other things) cut code bloat, reduce complexity, avoid feature creep, and reduce the restrictions on what can be done (and how it can be done) in the future.

I suppose it works in tandem with modular design: Future features can be augmented without redesigning existing code.

Brian M. Hunt
A: 

If it (the project) doesn't give you a hard-on, don't do it.

Chris
Women aren't going to be able to do any projects with this criteria.
Beska
A: 

When you start something finish it!
Use the other principles to achieve this.

Charles Beattie
+1  A: 

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." ---- Martin Golding

Jivko Petiov
A: 

One important aspect of programming that is often neglected and ignored is "Separation of concerns". Before starting to code, it is crucial to analyze and design your classes to ensure they are not tightly coupled. Otherwise you will end up with very dependent objects and code, which makes change very difficult and refactoring a nightmare.

Applications should be layered sufficiently and use of design patterns to decouple your classes allows for easy maintainence and ease of testing.

edfoh
+1  A: 

Besides not reinventing the wheel, you should understand how the wheel was built and what it really does.

blizpasta
+5  A: 
  1. Understand why the program will make someone happy (otherwise, why aren't you outside playing with all the other kids?). (This person can be you.)
  2. Develop a conceptual model of the business domain that captures all the needed complexity, and no more.
  3. Develop a conceptual model of the software architecture that captures all the needed complexity, and no more.
  4. Ruthlessly keep all other complexity out.
Dov Wasserman
well said! couldnt agree more
Antony
+1  A: 

There are only three things in the universe: data, containers for data, and tools that either put data in a container, take data out of a container, or change the data in a container, and they overlap.

J.T. Hurley
A: 

Humbleness.

mannu
+2  A: 

Paraphrasing Fred Brooks:

Representation is the essence of programming. Much more often, strategic breakthrough will come from redoing the representation of the data. This is where the heart of a program lies. Show me your code and conceal your type definitions and function prototypes, and I shall continue to be mystified. Show me your type definitions and your header files, and I won't usually need the bodies of your functions or methods; they'll be obvious.

And just to add a shred of originality, when you write down your data-structure definitions, document their bloody invariants already!

Norman Ramsey
+1  A: 

What is the simplest thing that could possibly work...

seanb
+1  A: 

SOC - Separation of concerns
KISS - Keep it simple stupid
DRY - Don't repeat yourself

in that order

Thomas Danecker
Aren't SOC and Dry redundant?
Neil N
I think they're quite orthogonal, sometimes even contradicting...
Thomas Danecker
+3  A: 

In my opinion, the most important principle is the reduction of complexity by creation of good abstractions.

This includes

  • understanding the problem to be solved,
  • designing an appropriate solution for it and
  • implementing it,
  • preferably in a way that keeps the code understandable and maintainable,

but also determination of the point where to stop creating abstractions and get down to the fundamental properties of the implementation technologies (e.g. database system, programming language) to prevent creation of avoidable additional complexity.

mh
+1  A: 

Knowing WHAT not to program is as (sometimes even more) important as knowing what to program.

Demian Garcia
+4  A: 

Think first, code later.

You're nowhere near as smart as you think you are. Ask questions. Learn to value your peers.

When debugging, the first answer will almost always be wrong.

Code you write with the intention of tossing out tends to become a cornerstone of much larger processes. Never leave anything written haphazardly.

Mike Hofer
+1  A: 

making it bug free.

Orkun Balkancı
but everybody makes crappy buggy software!!http://www.codinghorror.com/blog/archives/000099.html
yelinna
A: 

0 + 0 = 0

1 + 0 = 1

0 + 1 = 1

1 + 1 = 10

1 * 10 = 10

10 / 10 = 01

~ 0 = 1

~ 1 = 0

That is all there is to computers

Jim C
There's no such thing as 2. Maybe you meant 10 / 10.
ojrac
+1  A: 
  • The way of thinking is more important than pushing the actual buttons
  • All good programmers are lazy, but not necessarily the other way around (!)
peSHIr
+1  A: 

I would have to say that testing is one of the most important pieces of the puzzle. In my opinion test early and test often. Whether you design method is highly planned or agile there is nothing more important than testing to keep you on the right path.

Bill
+1  A: 

Understand the problem.

johnny
+1  A: 

Decomposition. Solve large, complex problems by breaking them into smaller, more manageable pieces.

And - style matters.

duffymo
+2  A: 

Indirection.

It might not be obvious why this is, or even what this means. But indirection is really at the basis of all of programming.

At a more superficial glance, it only seems to touch abstraction (as a concept), or perhaps also pointers (after all, they are the archetype of indirection). But pointers are just one instance (there! indirection!) of the concept, and there are many more, that are effectively equivalent upon closer examination.

First and foremost, variables are indirections because they allow the manipuation of a value indirectly via a symbol (name). As a direct consequence, functions are an indirection, because they replace one symbol (the formal parameter) with another (the actual parameter, or argument (sometimes, the definition is the other way round)).

Since classes are historically just functions in disguise, classes are obviously an indirection for the same reasons as functions.

Arrays (or lists, same thing) are another indirection, often exposed as a fundamental type. In fact, there is no difference between an array and a pointer. Both refer to other things, or none (in which case the array is empty, the pointer is null or a special placeholder, “not in list”: NIL).

I've recently read a paper where the pseudo code contained the following function, and use:

function UpdateItem(item, position) do
    P <- { }
    if item.x > position then
        item.count <- 0
        P <- { item }
    item.count <- item.count + 1
    item.x = position

Results <- { }
for something or other do
    position <- GetPosition()
    Result <- Result U UpdateItem(current, position)

The point here is that, like all good mathematical pseudo-codes, it operates on mathematical sets, and augments a Results set by joining it to another one. Now, how would one implement this? Obviously, we could just use a Set data structure, or an array, or a vector, or any of these. But usually, this is done via pointers, right?

item_t* update_item(item_t* item, int position) {
    if (item->x > position) {
        item->count = 0;
        return NULL;
    }
    ++item->count;
    item->x = position;
    return item;
}

item_t* result = (item_t*)malloc(sizeof item_t * N);
unsigned index = 0;
for (something; or; other) {
    item_t* r = update_item(item, get_position());
    if (r != NULL)
        result[index++] = item;
}

For me, this shows really well that many, many different programming concepts just implement/perform some kind of indirection and that, despite all their differences, most of them can be expressed in terms of other means of indirection trivially.

So yes, I think indirection is really the first principle of programming, since all others are just indirection in disguise. Except recursion. Of course, recursion can be used to describe indirection. ;-)

Konrad Rudolph
I didn't read all of that but yes indirection is the cornerstone of abstraction.
Ollie Saunders
+1  A: 

Do one thing, and do it well. It's the UNIX philosophy (http://en.wikipedia.org/wiki/Unix_philosophy). It works at every layer.

Rob K
+1  A: 

BE SMART AND LAZY

Just smart, and you will be engineering your way into bloated frameworks and writing UML until Duke Nukem Forever is released.

Just lazy and you are worthless, eating bon-bons in your sweats with no hope of amounting to anything.

If you are smart and lazy, that's where the money is. Engineering your way to nirvana by being pragmatic and recognizing ways to make your life easier daily.

Clint Simon
+1  A: 

When in doubt, manipulate the data!

SomeMiscGuy
+1  A: 

You have to resolve all the problems in the world with "if, for, while".

pmlarocque
+1  A: 

JFDI - Just @#*&^%$ do it.

A friend recently suggested that agile, waterfall, iterative, etc etc etc are a waste of time and the best way to write software is the JFDI school of thought. Not my mantra, but made me smile.

ng5000
A: 

This is a good question.

+1  A: 

Abstraction, Composition

pi
+2  A: 

Do no harm :)

Mike Sickler
+1  A: 

Beneficially relating elements.

This means that there are elements (modules, subroutines, whatever) that relate in order to benefit one another (nothing superfluous). This is part of Kent Beck's responsive design concept. There's a talk on it.

Ollie Saunders
+2  A: 

Use your head. It is terrifying how many people fail that one.

tomjen
+1  A: 
  • 20% code for function

  • 80% code for exception

+3  A: 

Always write code as if the person who will be maintaining it is a psychotic serial killer who knows where you live

Also, never think you know everything about programming, keep learning

Amy
+1  A: 

"Computers Are Blind, Deaf and Stupid".

I should tell this to that teacher (not a programmer) who thinks that the formula is enough for programming an app that makes math calculations. You must tell the computer what to do with that formula, doh!! (the same is for data from a BD).

Blind and Deaf... if you make signal and image processing, you know this.

yelinna
+1  A: 

It doesn't exist unless it's committed.

Kevin Pang
+1  A: 

Computers do ONLY what you tell them to. If it doesn't work right, its because you haven't "told it" (coded) it right.

2nd favorite: its usually a problem with you (your code) - interpret this as in "first look for bugs in your code, before blaming it on bugs in libraries you use"

Timur Fanshteyn
+1  A: 

Loose coupling. High cohesion.

nwahmaet
+1  A: 
  1. Think First
  2. See 1.
+1  A: 

Always code as if the person who will maintain your code is a maniac serial killer that knows where you live

No idea where that phrase originated from (possibly from some humorous caption), but I think there is some truth in it: Code for maintainability. If other people can maintain it, then that usually means that it's kept simple and well structured for the most part.

Michael Stum
+1  A: 

Don't be stupid on purpose

Mike Two
+1  A: 

Code is written once, and read many times. Optimize for the reader.

ojrac
A: 

We are morons.

Captain Segfault
A: 

So, what do you think is the first principle(s) of programming? I'll give my answer below a little later.

  1. Never trust data from users or other sources.

In other words, always check data for validity first. Bad (or unexpected) data can create havoc.

osij2is
A: 

I'll second DRY and KISS. I'd also add, "Knowing a language is not the same as knowing how to program. Just like knowing how to use the steering wheel is not the same as knowing how to drive." Learn fundamental principles, and then apply those using whatever language or tools you have available. Languages and database engines and the like come and go. Data structures and algorithms are forever.

Jay
A: 

Ask Questions first.

SP
+1  A: 

I think that one consequence of the Church-Turing thesis is that any algorithm that can be thought of, can be programmed on a machine.

It makes it incredibly hard to tell a manager/a client 'this is impossible' because in theory, if you can describe it, it is possible.

The rest is a matter of resource. The difference between a programmer and a non-programmer is that a non-programmer will ask for features which will range from 5 minutes development to 5 billion years, and they will be equally happy with each one of them. I exaggerate a bit, but that's the idea.

So here's the first rule of programming:

Maximize your 'end users satisfaction'/'resource' ratio.

jeje
I don't know that that's the "first principle", but it's a good one.
Jay