Once upon a time I was a loud mouthed, big headed, my code could never be wrong, I'm invincible...
Kind of programmer...
Over time you will, unless you never go out, you will meet programmers who know more things about you, either about everything, or about certain specific things, and you have to learn to evolve and understand they just know more than you.
They might have been through the problem you're wrestling with for the first time, they might have worked on the base system, or they might just recognise the pattern of the problem you've got.
So don't just dismiss these folks, they know what they're talking about, and even if they don't take it, analyse where they've gone wrong and you learn from it, do not do what happened to me...
We're about six years ago now, and we had a graphical system, this system had been running games from many different sources for several years (about four) so it was a tried system, the hardware was known, it had known bounds and I personally had handled maybe a dozen different people working on it before, their games all worked, and I turn around and can see 32+ games working still to this day.
One thing I don't see right now however is this game from this one guy, because... He's a douche, and I don't actually see him because he no longer works here, of all the folks in his department he was the first gone of his own accord, because... well because he was one of those programmers, one of those people who never really grew up, he considered himself above reproach, he was perfect, his code was perfect and any issues were yours.
So, let us just dive off to games, games at their heart have a loop, which reads/updates the data, plays sound and critically updates the graphics, that's the core of all games from Battle Chess to Call of Duty, this game loop is time critical, if you delay the update or the display the game will look like it's stuck, or juddering, people often call this lagging, but the problem is that loop for interrupted to things didn't look smooth or play smooth.
But computers are fast! So for most trivial problems the data can be updated and the display redrawn faster than the hardware is actually limited to, so the hardware is done and sat idle waiting for the next rendering of the game.
This is called the sleep or delay, and games use this time to do other things, like perhaps check for updates or sort data.
Now this delay has to be controlled, you have to make it a fixed length, or set it up so that the machine works out how long the work it did was since it last drew the screen, and wait for the difference in time to smooth out the drawing. This makes the game play smoothly, makes animation behave smoothly...
So, if you have a loop and you just randomly sleep for X time, but then the data processing you're doing takes longer than X the game will look like it's stuttering.... How can this happen?...
Well, how about this code:
while ( true )
So, we update, then draw ,then sleep for 1 second.. okay, but what if the processing in "update" takes 800ms, how long will we take between draws now?... How about 1.8 seconds! So that cycle the game will look like it took nearly twice as long to draw, and animations will stutter.
What has this got to do with programming?
Well, once upon a time this very code above strolled into view, and the programmer working with it kept saying "your machine is making my game stutter, it runs fine on my machine"... His machine being a more powerful machine with dual core and more RAM... So I pointed this out, he then set about trying to explain it all away.
When he then showed me this code, I just pointed at the sleep and went back to my desk, it was not my job nor part of my remit to work or debug his code, I saw this problem was simply he wasn't changing how long he slept for, but also he was very confrontational, because the contract with the "Sleep" function on Windows (the platform we were using) is not quite what most programmers expect.
You see sleep will go away and pause a process/thread for X amount of time, and it will come back to continue processing up to or after that time... Up to or after... Not immediately, so in a game you can't guarantee that the Windows Scheduler will pick up your thread and come back to your program immediately after 1000ms above!
I told this chap this, and he flat argued, he even went so far as to print out the MSDN documentation pointing out that I was wrong, and I was a wanker, and he went on a tirade around the office.
It was only later I went back and pointed out that he was referencing the sleep function for Windows Mobile, not Windows XP, and going to the right Operating System on the MSDN page, it said "upto or after the delay".
He didn't say sorry, he didn't say anything, he actually sat down and said "fat wanker".
Lucky for him my boss was stood right there and heard him say this, so I left them to it, but I never spoke to this cunt every again, he left the company soon after, he'd apparently agitated not just me but about six other people, arguing when they knew their stuff and then insulting them.
He was perhaps the third worst person I've worked with at this company.
For information about how sleep works, and how variable it can be, check this out.