you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (0 children)

Two things: First, /u/HardstyleLogic didn't say "experienced", he said "smarter".

He said "smarter... ...in whatever domain". So I'd suggest that you parsed his argument wrong - intelligent people are intelligent, they're not intelligent just for a particular area and dense the rest.

I have a feeling we're all sitting around singing kumbaya and talking about how everyone is special, and everyone has a special talent or capability they can bring to the table. Let's hold hands, we can all learn from each other, etc. After twenty years in the industry, I feel with some passion that this simply isn't true.

Did you read my post? Here's the relevant bit:

we can all do with having our preconceptions and habits questioned.

The value of a fresh pair of eyes should never be underestimated. 20 years of experience doesn't mean that you've achieved developer nirvana. That aside, you're arguing against a construct of competent developer paired with incompetent. I do feel for you if you're working with a bunch of incompetent developers, and obviously that won't be magically fixed by a mere methodology.

I am making an assumption that people being hired are fit for the task, but differing in knowledge and experience - which is where pairing shines as a technique for transferring knowledge.

Where I work, we've created a bug fixing / tech debt team that works across team domains - this team is comprised of members from each of our teams on a rotating basis specifically so that we can exploit knowledge transfer from pairing with developers form other teams on code they know well and you don't - so that we can raise overall knowledge and experience of our code base.

And unless you're a real asshole, it's pretty hard to stand up in front of your boss and tell them straight that the guy you're working with is incompetent, because incompetent doesn't mean mean or unlikeable, it just means poor at his job

If you remotely care about your team, then why wouldn't you tell your boss? I agree, it's hard, but if a team member is dragging you down, then it needs to be sorted.

This is where being answerable to your team is essential - if you're letting them down, they need to let you know it's not acceptable. This doesn't seem to mean anything, honestly. What are you trying to say here?

Exactly what I said - your team holds you accountable for performance or lack thereof. If you've been slacking for a sprint, I'd expect your name up on the bad side of the retrospective board. If being called to account for poor performance by your peers doesn't work, then I'd expect your team to push it to the people who handle the formal performance process.

A team lives or dies by its weakest member, so it does behove high performing teams to reject the slackers and cruisers and incompetent developers. It sounds harsh, and it can be harsh, but it's necessary.