Ask HN: What are some strategies to create positivity in the engineering cycle? | Hacker News Reader

Ask HN: What are some strategies to create positivity in the engineering cycle?

3 pointsMattyRad5 comments

The process of software engineering is rife with negativity. Some examples:

  - Code review is important, but it is a necessarily a critique, and sustained code review can wear both submitter and reviewer down.
  - Bugs happen. And they get fixed! But you'd be lying if you said you didn't check to see if you were the one that introduced the bug.
  - Dealing with fires.
  - Staying on top of security is constant and infrequently terrifying.
  - Open source software rarely sees all the value it brings to the table; conversation usually focuses on issues and shortcomings.

Negativity abounds. It's a wonder that all of our mental states aren't reduced to the equivalent of an anxious chihuahua. Has anyone been successful in introducing some positivity in the engineering process? I have precious few examples:

  - GitLab selects an MVP [0] for its releases, putting their name at the top of the release notes, very publicly awarding recognition.
  - GitHub has introduced the "Discussions" page recently, frequently containing a "Show and Tell" category [1], helping open source maintainers see their hard work in action.
  - Gamification and badge awarding has been explored [2], although it's non-trivial to introduce (and if there's talent disparity on a team, leaderboards and badges could actually be demoralizing and counter-productive)

> Note: While ideas like go out for beers with the team once in a while is helpful, I'd say that's more of a social band-aid. I'd like to focus the conversation on the engineering process specifically.

[0] https://about.gitlab.com/releases/2021/01/22/gitlab-13-8-released/

[1] https://github.com/laravel/framework/discussions/categories/show-and-tell

[2] https://www.dalsat.me/download/publications/saner2017.pdf&sa=U&ved=2ahUKEwiluunw6fjuAhVgJzQIHWLQDQsQFjAAegQIAxAB&usg=AOvVaw1yAwqK5Vjml9jXFR7Bhxk0

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.

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)

That being said I still think you have an insightful response, thank you.

> 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.

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.

Can’t beat the kinds of feedback that reinforce meaning in relation to needs, outcomes, purpose etc. When “done” is someone’s need met.

Reply on news.ycombinator.com