Post 'em here!

How about q-tips? I am still working on my Costco size supply of q-tips and have plenty to share.

Follow code conventions.

Learn as many languages as you can.

Write your own language.

Hang out on irc, mainly freenode.

Smaller, lighter, faster is better.

Start a development blog.

Focus on one big project.

Refactor, your code sucks the first time around.

The big criteria are Coupling, and Cohesion.

There are two major kinds of parsers -- LL(x) and LR(1).

Good stuff thanks guys.

(fuck you son)

Keep

It

Simple

Stupid

anytime stuff starts getting complex, ask yourself "is this worth it?"

Surprising how often the answer turns out to be "no".

KISS is a good one, and most programmers know it, but I dont understand why so few follow the practice.

Sometimes I try to ask myself, if I were to give my code to a non-technical person could he figure out what was going on and possibly maintain my code.

Get something working, then refactor.

Try the most obvious solution. 

Optimize later.

Use the style/conventions of the language, environment, or platform you are using.  Don't use a C++ coding style with Perl (or vice-versa).

"anytime stuff starts getting complex"

Software naturally starts getting complex as more and more features and functionality are added.  It takes more time and effort to make things simple than just tack on code as needed.  You *will* end up with a big ball of mud if you don't go back and refactor.

Most companies will not give you the time to back and refactor.

"KISS is a good one, and most programmers know it, but I dont understand why so few follow the practice."

I swear by it, yet I'm just getting to the end of a big chunk of work on a project where I realise I added about 15% of effort in stuff that was not really needed, had I thought the way it would be used through.

That's why it always bears repeating. It sounds obvious, but very very few systems are designed at maximum simplicity and elegance the first time through.

Keep a file of common idioms of the current language and system you're in.  Some of those you will cut and paste (gasp!) and some are opportunities to make a library function.

rocco's are good too.

yeah Wayne, I know. The point is in having the design that makes the complexity look simple, which takes a lot of thought. I know it rarely happens in a commercial environment.

I don't usually do the KISS thing.  I create classes/functions/methods that I think I'll need sometimes before I need that.  Sometimes that works out extremely well I end up saving myself a ton of work than if I've gone the other way.  Other times, it's just code that needs to be removed on the next refactoring.

I know people hate it, but I kind of dig it.  In hibernate and spring you can write your business logic with one line of code:

For example to get a record and return a List of the database objects.

List list = getHibernateTemplate().find("from Customer");

That is it.  same with saving a record.

To me, that defines simple.

its similar with the perl library (DBIx::Class) I use for db layer, bot. Also, if you define relationships correctly, there are all kinds of joins and so on you don't have to worry about.

I just figured out for my program, ran into this last time I tried to make something bigger than a tiny program.

It comes back to first thing learned at DeVRY in COBOL class, decomposition diagram.  Pencil and paper, or maybe a Visio.  Write out the input and output files, all of them.  Figure out where the for-next loops are going to be and exactly where to divide up the processing into functions.

It's not even pseudocode, it's higher level, it's architecture, that seems to be a bigger stumbling block of wasted time and uncertainty, to me.  How do you cope with size, scale of program (?)

That last tip pertains to my perl programs, BTW.  The language chosen shouldn't interfere with the logical structure of the program, I should hope.

When working in a team, the goal should be to write code that looks like one person wrote it all.  This will give you the most consistency and easy maintenance.

This can be achieved partly through standards, partly through code reviews, but mostly through assembling a team that thinks alike.

stay current and read up about all the latest, but keep perspective and choose technologies wisely.

Don't forget to get paid.

If your specs aren't any good, it doesn't matter how good you are.

or the clients ...

http://en.wikipedia.org/wiki/The_Gambler_%28song%29

... applications (some legacy apps are the walking dead).

KISS doesn't necessarily mean less code (though it usually does).  Some pieces don't play well together, so don't force it. 

Good names are key for variables, objects, tables, functions, procs, etc.

You can learn from both good code and bad code.  Looking at the way others code is a great way to improve your own techniques.

I regularly (although I haven't recently) download open source code just to look at it and see how they do things.  I've found some really great techniques over the years that I've incorporated into products.