"I want to say I'm proud of something I did."
There aren't very many times Kris says this to me. I don't believe it's because he isn't proud, he does some great things and should be proud of those things. I believe it's because he doesn't need to say that he's proud of them, because he's happy with what he does, and his happiness at his success is sufficient. So, when he said that he was proud of something, I stopped what I was doing to listen.
"I'm proud that I assume my code, and not someone else's code, is causing problems on merge or checkin."
I smiled. I thought it was an odd statement until I thought about it more.
I lost count of the number of times Arnaud would yell, "This is shit!" at work, and claim the problem we're having on launch is TFE, without actually determining the root of the problem. I lost count of the number of times one department blames the other department, without actually fully understanding the problem. I lost count of the number of times a software guy says it's a hardware issue and the hardware girl says it's a software issue. I lost count of the number of times Kris told me stories about the long-ex-coworker who would merge, find conflicts, and tell Kris to revert his code back a couple versions so that the ex-coworker wouldn't have merge conflicts.
Merge conflicts are a fact of life in development. Put on your big boy pants and deal with them.
It's easy to say, oh, this change is someone else's fault, because we want to be right, we want to believe our work is clean, and that any issue is with someone else's work. It is rare that someone is always right (unless you're Arnaud and you're talking about me, in which case, I am always right). And yet, the easier case is to blame someone else.
And Kris doesn't do this. Merge conflict, something he did, let's check it out. Test not passing, something he changed, let's check it out. New bug introduced in the last build, something he did, check it out.
It's a different perspective than most people have. I think it's the perspective most great developers have.