Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.


locked by maple_shaft May 15 '13 at 16:40

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

93 Answers 93

The Binary System

0 + 1 = 1
1 + 1 = 10
10 + 1 = 11
11 + 1 = 100
100 + 1 = 101
101 + 1 = 110

Get it?

Can't vote down right now. But will do :D – pongba Oct 1 '08 at 19:19

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.


Ask Questions first.


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


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.


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.

  1. KISS - Keep It Simple Stupid
  2. DRY - Don't Repeat Yourself
  3. YAGNI - You ain't gonna need it
I think KISS should be "Keep It Simple, Stupid!" – Dennis Cheung Dec 9 '08 at 16:33
I would also add YAGNI. – Daniel Straight Mar 9 '09 at 12:29
@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 Jul 31 '09 at 19:01

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


Don't be stupid on purpose


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.

  1. Think First
  2. See 1.

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"


It doesn't exist unless it's committed.


"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.


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.


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

  • 20% code for function

  • 80% code for exception


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


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.


Do no harm :)


Abstraction, Composition


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.


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



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.


When in doubt, manipulate the data!


Do one thing, and do it well. It's the UNIX philosophy ( It works at every layer.



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->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. ;-)


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

And - style matters.


Not the answer you're looking for? Browse other questions tagged or ask your own question.