In search of strengths: when done is not done

A weekly meeting, and an unusual argument:

P: Oh, that feature of mine is ready. It's been ready now for a week. I would have already put it in production if you did not make up a rule that I can't.
T: Hmm, I must have missed something. So it's ready? You fixed all the problems. Last I tried it two weeks ago, it did not really even start.
P: It has worked for me all the time. But I did some tweaks. There was nothing significant. Just give to the customer.
T: We'll team up to test it and see where we are. We're delivering when it's team-definition ready.

It's been such a long time since I've had to endure these discussions, that I almost forgot what they are like. And that they were the standard style of discussion some 20 years ago. For most part, I'm glad those days are gone.

But what's going on here, really? Story continues with three people testing the feature in a group.

T: So, let's just go through the basic flow. This was the command, right? (setting up the data to something a user could use, instead of the developer specific version)
P: Yep. Just run that and it all works.
U: I have a few UI specific remarks, let's go though those in the context of use
P: I hate this nitpicking, couldn't you just go and fix it in the code?
T: Let's just see how it is. Oh, it crashed? It doesn't do that for you?
P: No. I guess there's a bug there. 
T: Oh, I know. This is because you expect this other thing to be run first, right? But look, my data has three things and this list has only one. 
P: The other application is done by someone else in the team, I just move the data here. But I guess there's a problem. But there's another developer who worked close to this area, talk to him first
T: Ok, so this is the summary page.
U:
T:
P: Did you have a picture of how that was supposed to be?
U: And there's still this one thing we need to improve we just talked about
...
T: Let's sum it up. Five dialogs, 2 months of work on the must do list and more on the later iterations list we thought would be in now. See why we disagreed on done yesterday? Could we work out something so that you'd believe the two of us actually know a thing or two about the product and its use, and we'd need to collaborate?
P: I guess I go work on this stuff more. 

This story has background that is not visible in these discussions: knowledge of bad code design, bad choices of how things are implemented and a 3-year experience that fixing just makes things worse. So I ask:

There’s loads of stuff on hiring, but is there anything good on having hired a wrong one and needing to live with it?

— Maaret Pyhäjärvi (@maaretp) February 19, 2016

Here's the answer I love the most:

@maaretp we evaluate strengths and weaknesses and use the person accordingly. In my experience training rarely dramatically helps.

— Jukka Talvio (@Jukka_Talvio) February 24, 2016

Now, in search of the strengths I work on empathy and hope the programmer would stop opting out of our team mob Thursdays. People are the way they are because of environment and experiences. Play the strengths. And accept that conflicts can turn into something positive, even if they are draining.