Share your wisdom! Sage thoughts related to programming you've discovered over the years

"Always code as if the guy who ends up maintaining your code

will be a violent psychopath who knows where you live."

- John Woods, 1991

(note that this quote gets attirbuted to a lot of people and I'm only like 5% sure John Woods was the original speaker)

Not mine, but there's a few people I wish I could beat this into...

As for my own:

"You should never delete/delete[] what you new/new[]

because you should be using smart pointers anyway.

And if you can validly disagree with me, I'm not talking to you."

- Cornstalks, 2013

"Always document your code."

- alnite, 2013

If you don't understand why, you will sooner or later.

"Understand a bug first, before fixing it."

"Keep it simple and stupid."

"Hunt down a crash immediately before its tracks disappears."

"I will always give the hardest tasks to the laziest worker, because then I'm sure, that the most simple solution will be developed" (not from me)

"Perfection is archieved not when there is nohgin more to add, but when there is nothing left to take away" (not from me)

“‘Warning’ is just a misspelling of ‘error’.” Me.

L. Spiro

KISS

Dont over complicate stuff by making generic solutions

eg do this

if ( actor == tank ) {

do this & that

}

and not this

if ( actor == has tracks ) {

do this

}

if ( actor == has a turrent ) {

do this

}

To paraphrase Bach, "Programming is easy. All you have to do is to hit the right key in the right order and the computer will run itself."

one of my senior Programmers gave the team a copy of some Truisms from " The Pragmatic Programmer" which Helped me tremendously. a few of my favorites were:

Care About Your Craft - Why spend your life developing software unless you care about doing it well?

Remember the Big Picture - Don't get so engrossed in the details that you forget to check what's happening around you.

Invest Regularly in Your Knowledge Portfolio - Make learning a habit.

Eliminate Effects Between Unrelated Things - Design components that are self-contained. independent, and have a single, well-defined purpose.

Fix the Problem, Not the Blame - It doesn't really matter whether the bug is your fault or someone else's – it is still your problem, and it still needs to be fixed.

Use Tracer Bullets to Find the Target - Tracer bullets let you home in on your target by trying things and seeing how close they land.

The first three may seem obvious but to me the programmers i know who are working after college understand and work according to these ideas, the ones who didn't and don't aren't. The last three have personally grown more valuable to me over the course of my career. Having code that's independent of each other leads to fewer Errors " The ways this can break are limited because this only does X, Y, And Z" , it has made debugging substantially easier to me. Fixing problems and not blame is huge too , when a team constantly throws blame around instead of fixing issues it causes distrust issues and still someone has to go back and fix the code, why not cut out the middleman(frustration) and fix the code right away avoiding unnecessary drama ? Lastly using Trace Bullets is always an effective Debug Means it let's you see what your system is actually doing versus what it is REALLY doing.

Here's a link to some other pragmatic programmer truisms just in case anyone's interested: http://www.codinghorror.com/blog/2004/10/a-pragmatic-quick-reference.html

Here's a link to some other pragmatic programmer truisms just in case anyone's interested: http://www.codinghorror.com/blog/2004/10/a-pragmatic-quick-reference.html

Don't Live with Broken Windows

Windows 7 crashes so often for me I can’t watch a single episode of Tiny Tunes.
Windows XP crashes so often I can barely get in one episode of MacGyver.

I don’t live with broken Windows by choice. It just happened.


L. Spiro

"If you're going to be writing cryptographic code, and you're not sure what you're doing,

just put the keyboard away and ask someone qualified to write it for you. For all our sakes."

- Bacterius, 2013

Or, really, the more general statement - if your code is going to be used in situations where it failing could have very real consequences, don't write the code if you cannot assume said consequences. Seriously, the Dunning-Kruger effect is omnipresent in the field of programming, and not taking it into account is a recipe for disaster. See the recent utter failure of the Mega file sharing website's launch - the developer had no clue what he was doing, and the result is painfully obvious and predictable.

cc

"Whatever new language or paradigm doesn't kill you makes you stronger"

-szecs, 2013

The pinnacle of programming is mastering the remotes for your entertainment systems

-Stormynature, 2013

It sounds a little generic and overused but after you've had to refactor several projects and subsequently write them from the ground up, you'll think twice before coding the idea that sounded awesome in your head.

right on! My first ACB ran seeemingly well, until i realized it had a core architecture flaw. Some replanning, and now its 200 times faster and now manages my behavior forest for my game AI

Which leads me to one of my favorite quotes:

"Plans are Nothing; Planning is Everything"

-Dwight D. Eisenhower

and a personal favorite corilary of mine:

"Agile is Nothing without Planning, unless you like getting to crap fast"

-NetGnome, 2013

"In time you will come to hate the users; might as well get ahead of the game on that..."

A rule which everyone should be following; "Trust in the Rob, the Rob is good..." based on the recent trend of I suggest something, this is dismissed in favour of another idea, 2 months later it has been refactored to what I first suggested...

Damn it, copy & paste!!!

me.

Design patterns are descriptive, not prescriptive. Treating them as if it were the other way around (in my experience) generally leads to over-engineering.

A few on optimisation:

"Make it work. Make it right. Then make it fast"

- Kent Beck (I think)

"The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet."

— Michael A. Jackson

On debugging:

"Everyone knows that debugging is twice as hard as writing a program in the first place.
So if you're as clever as you can be when you write it, you are by definition not smart enough to debug it"

- Brian Kernighan

(paraphrased, because I'm too lazy to find the exact quote)

and on that note....

"Laziness is a virtue. A truly lazy programmer will do an immense amount of work just to avoid doing a small amount of work over and over again. This is a Good Thing (tm)."

- ChaosEngine

As with music, technical proficiency will only carry you so far. At some point you have to have a connection with your users, and those who must maintain your code; never neglect your social empathy in the pursuit to be a better technician.

Throw away prototype code.