In every profession there are truisms that are as elusive as they get, but absolutely require you to come to terms with. Everyone discovers these with practice - some sooner and some later. With me, usually the latter tends to be the case . If something like this has happened to you, share your revelation and wisdom! The only thing you have to do with your thoughts is to put them in the form of a sage-sounding quotation so I can collect them in this post. Like this:

"The most difficult thing about game programming is not writing the code,

but understanding what the code is supposed to be doing."

- Irreversible, 2012

"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

"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

"Understand a bug first, before fixing it."

"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

"Plans are Nothing; Planning is Everything"

- Dwight D. Eisenhower

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

- phantom

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