59
votes

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.

1
  • We do not talk about fight club.
    – Job
    Commented Jul 10, 2011 at 14:25

93 Answers 93

97
votes
  1. KISS - Keep It Simple Stupid
  2. DRY - Don't Repeat Yourself
  3. YAGNI - You ain't gonna need it
12
  • 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
    Commented Dec 4, 2008 at 8:35
  • 8
    I think KISS should be "Keep It Simple, Stupid!"
    – Dennis C
    Commented Dec 9, 2008 at 16:33
  • 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
    Commented Jan 8, 2009 at 20:11
  • 10
    I would also add YAGNI.
    – Daniel Straight
    Commented Mar 9, 2009 at 12:29
  • 3
    @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
    Commented Jul 31, 2009 at 19:01
37
votes

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

7
  • This is a very practical heuristics, 3x :)
    – pongba
    Commented Oct 1, 2008 at 19:08
  • 19
    Write code as if an axe-wielding psycopath will have to maintain it. FTFY. Commented Oct 1, 2008 at 19:08
  • 10
    ...and the axe-wielding psychopath knows where you live.
    – CAD bloke
    Commented Oct 8, 2008 at 20:24
  • 2
    ..,and he has just sharpened his axe...
    – Roalt
    Commented Mar 9, 2009 at 9:56
  • 1
    ... and he is working by your side. Commented Jul 31, 2009 at 18:33
28
votes

Be as lazy as possible.

8
  • 2
    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
    Commented Oct 1, 2008 at 19:10
  • This is a reference to perl's "Laziness, Impatience, and Hubris"
    – Ólafur Waage
    Commented Oct 1, 2008 at 19:21
  • 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
    Commented Oct 1, 2008 at 19:31
  • 2
    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.
    Commented Jan 8, 2009 at 21:21
  • 3
    @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
    Commented Jan 12, 2009 at 12:58
23
votes

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.

3
  • Uh, and then again: I landed in Zen land whilst speaking about programming :)
    – Georgi
    Commented Oct 1, 2008 at 21:46
  • @part III - don't add "fancy new stuff" unless you're getting paid to do it!
    – Jason
    Commented Jul 31, 2009 at 18:35
  • +1 for the Matrix reference. I'm a sucker for a good one (that and the Zen. Makes me think of Python)
    – new123456
    Commented Feb 14, 2011 at 22:35
19
votes

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.

8
  • I think this is a too general rule. It begs the question "how do you define 'simple', really".
    – pongba
    Commented Oct 1, 2008 at 19:06
  • 3
    and if you're stupid, how would you know if it was simple? Commented Oct 1, 2008 at 19:07
  • That's a good one, Steven :)
    – pongba
    Commented Oct 1, 2008 at 19:11
  • 1
    "This is why you cannot become a good programmer just by knowing the first principle of programming" - love it.
    – yuval
    Commented Jul 31, 2009 at 18:33
  • 1
    @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. Commented Aug 1, 2009 at 21:48
18
votes

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

1
  • Whether in implementation OR design.
    – Epsilon
    Commented Oct 2, 2008 at 3:02
16
votes

Do not reinvent the wheel.

4
  • 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
    Commented Oct 1, 2008 at 19:13
  • 5
    Some "wheels" need to be reinvented.
    – CrashCodes
    Commented Oct 1, 2008 at 19:45
  • 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
    Commented Oct 1, 2008 at 20:36
  • 3
    How about: Only reinvent the wheel if the benefits will be worth the costs Commented Dec 9, 2008 at 16:19
16
votes

Understand the problem first!

4
  • 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
    Commented Jun 22, 2009 at 10:22
  • @e-satis: Yeap, that what I thought when I first answer this. I scroll for all the answer and surprisingly nobody posted before.
    – OscarRyz
    Commented Jun 22, 2009 at 18:42
  • Good answer. Hours and hours get wasted when programmers don't properly understand the full requirements of a problem. Commented Jul 31, 2009 at 19:10
  • Problem is: how do you you know you understand the problem? Commented Mar 17, 2011 at 21:20
13
votes

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.

12
votes

Knowing when not to program.

7
  • what on earth is this supposed to mean?
    – anbanm
    Commented Oct 1, 2008 at 19:32
  • And when is that?
    – pongba
    Commented Oct 1, 2008 at 19:34
  • Sometimes you need to tackle a users problem differently - not just code a solution.
    – RichH
    Commented Oct 1, 2008 at 20:01
  • Human judgement and decision-making are part of everything; sometimes there's no point in trying to automate judgement.
    – S.Lott
    Commented Oct 1, 2008 at 20:05
  • 1
    What he means is that many programming problems can be solved cheaper and more timely by purchasing off the shelf applications, components, or libraries. Commented Oct 3, 2008 at 5:08
11
votes

Coffee in, code out.

2
  • 3
    Tea in in my case =)
    – Clox
    Commented Aug 3, 2009 at 16:36
  • +1 hmm more like "Coffee In, Code + lots of loo breaks?" :) I love both Coffee and tea, I swing both ways...
    – Darknight
    Commented Jul 10, 2011 at 14:17
10
votes

If it wasn't tested, it is broken.

1
  • I agree on that one
    – Clox
    Commented Aug 3, 2009 at 16:37
7
votes

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

6
votes
  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)

5
votes

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

5
votes
  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.
1
  • well said! couldnt agree more
    – Antony
    Commented Jun 14, 2009 at 12:20
5
votes

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.

4
votes

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!

4
votes

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

2
  • 6
    That's not true, I've written tons of code that works and isn't tested! :D
    – Gavin Miller
    Commented Jan 8, 2009 at 19:15
  • 1
    "I haven't tested it, I have only proved that it is correct" :) Commented Jun 22, 2009 at 10:27
4
votes

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.

3
votes

Any problem can be solved with another layer of indirection.

3
  • Actually, having too many indirections is itself an issue waiting to be identified and resolved. So..
    – pongba
    Commented Oct 1, 2008 at 19:15
  • resolved... by another layer of indirection! =) Commented Oct 1, 2008 at 20:55
  • Oddly enough, its true. Look at Spring...
    – Joshua
    Commented Oct 3, 2008 at 13:16
3
votes

Know your tools.

3
votes

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.

3
votes

Write code for the next guy.

3
votes

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

2
votes

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.

2
votes

It's all about the user.

2
votes

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

2
votes

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.

2
votes

Start with the output and work backward.

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