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 document your code."

- alnite, 2013

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

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

}

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