4 ms·

If you have no steps in between assignment and code review, then the problem is not code review. companies will realize that putting a single developer on an e

If you have no steps in between assignment and code review, then the problem is not code review. companies will realize that putting a single developer on an engineering problem, and having the solution be submitted for review to the rest of the team after the solution has been designed is both unkind to your employees and bad business. Let's give people a little agency here. "Companies" can't realize anything. If you, as a software engineer, are operating this way and blaming it on "the company" then you are part of the problem. You are the company. Do it better and it'll be better. External locus of control, and using "the company" as a scapegoat to absolve oneself of responsibility, is what's ailing such a company.

skybrian 8y ago
Just like code review doesn't happen on its own, pair programming does need to be a team effort. A single developer deciding to do pair-programming more tends not to change an entrenched culture. Working in the same place and time and on the same code change doesn't happen automatically, particularly in places that support flextime and working from home. The one place I worked where we pair programmed all the time and it worked well was a startup where everyone hired knew going in that it's an XP shop (and this was part of the attraction). On the other hand, flextime and working from home actually are important benefits. It's a tradeoff.
eecc 8y ago
Ho Hero! Go ahead and get crucified in the Cafeteria, I’ll wait and see if you come back after 3 days /s Hmm, I can already hear “he’s not motivating the team”, “he needs to align more to the priorities instead of insisting on process. That’s not Agile!”, “his energy is low”, “he’s taking focus away”... sounds familiar?
- solipsism 8y ago
  Um, what? Is any of that supposed to be related to the conversation we're having?

skybrian 8y ago

Just like code review doesn't happen on its own, pair programming does need to be a team effort. A single developer deciding to do pair-programming more tends not to change an entrenched culture. Working in the same place and time and on the same code change doesn't happen automatically, particularly in places that support flextime and working from home. The one place I worked where we pair programmed all the time and it worked well was a startup where everyone hired knew going in that it's an XP shop (and this was part of the attraction). On the other hand, flextime and working from home actually are important benefits. It's a tradeoff.

eecc 8y ago

Ho Hero! Go ahead and get crucified in the Cafeteria, I’ll wait and see if you come back after 3 days /s Hmm, I can already hear “he’s not motivating the team”, “he needs to align more to the priorities instead of insisting on process. That’s not Agile!”, “his energy is low”, “he’s taking focus away”... sounds familiar?

solipsism 8y ago
Um, what? Is any of that supposed to be related to the conversation we're having?