4 ms·

Trying to manufacture positivity through policy or forced work requirements rarely has the desired effect. Most people see this for what it really is: Another p

Trying to manufacture positivity through policy or forced work requirements rarely has the desired effect. Most people see this for what it really is: Another performance they have to put on to appear as one of the positive people. The only sustainable solution I've found is to lead with positivity, and not tolerate negativity. Put people who can lead with positivity in management positions. Remove negative people from leadership roles. Don't tolerate negativity. > Code review is important, but it is a necessarily a critique Code review is only negative if you frame it as such, or allow the team to frame it as such. We frequently have to mentor new employees to understand that code review comments are not equivalent to social rejection, not equivalent to being demeaned, and are simply a constructive group learning process. This is where positive leaders are essential: If your leaders are introducing code review as "Yeah, it sucks to get your code torn apart..." then everyone is going to view it as a painful process where the goal is to please your peers. If you instead introduce code review as "Code review is a great way to get feedback, get some more eyes on your code, hone your skills, show others what you're doing, and spread understanding of your domain" then people tend to start to like it.

MattyRad 6y ago
I think that's a good point about manufactured positivity, and it makes me wonder if the question I've asked is itself flawed. I think your solution of promoting positivity to management positions carries its own concerns though, such as promoting naive yes-men, or "fronting" positivity so much that it becomes fake (for example, the "failure == success" bit from Silicon Valley HBO, if you're familiar https://m.youtube.com/watch?v=u3o8Cygx1EU https://m.youtube.com/watch?v=u3o8Cygx1EU) That being said I still think you have an insightful response, thank you.
- PragmaticPulp 6y ago
  > I think your solution of promoting positivity to management positions carries its own concerns though, such as promoting naive yes-men, or "fronting" positivity so much that it becomes fake Promote more of what you want to see. If you see a yes-man or someone pedaling fake positivity, don't promote it. No one is a perfect judge, but keep your eyes open. You get more of what you incentivize.
- cratermoon 6y ago
  I agree with the warnings about "forced positivity", and I'd like to suggest looking at the boundaries between engineering and the rest of the organization. In many cases I've seen the engineering team mired in negativity because the product owners, the sales and marketing people, and even senior leadership have an uncharitable view of their own programmers. The engineering team knows that, even if it's papered over with happy talk. Under those conditions, code reviews, firefighting, squabbles over tools/methods/conventions, and many other things will reflect that lack of support.

MattyRad 6y ago

I think that's a good point about manufactured positivity, and it makes me wonder if the question I've asked is itself flawed. I think your solution of promoting positivity to management positions carries its own concerns though, such as promoting naive yes-men, or "fronting" positivity so much that it becomes fake (for example, the "failure == success" bit from Silicon Valley HBO, if you're familiar https://m.youtube.com/watch?v=u3o8Cygx1EU https://m.youtube.com/watch?v=u3o8Cygx1EU) That being said I still think you have an insightful response, thank you.

PragmaticPulp 6y ago
> I think your solution of promoting positivity to management positions carries its own concerns though, such as promoting naive yes-men, or "fronting" positivity so much that it becomes fake Promote more of what you want to see. If you see a yes-man or someone pedaling fake positivity, don't promote it. No one is a perfect judge, but keep your eyes open. You get more of what you incentivize.
cratermoon 6y ago
I agree with the warnings about "forced positivity", and I'd like to suggest looking at the boundaries between engineering and the rest of the organization. In many cases I've seen the engineering team mired in negativity because the product owners, the sales and marketing people, and even senior leadership have an uncharitable view of their own programmers. The engineering team knows that, even if it's papered over with happy talk. Under those conditions, code reviews, firefighting, squabbles over tools/methods/conventions, and many other things will reflect that lack of support.