TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

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

3 pointsby MattyRadabout 4 years ago
The process of software engineering is rife with negativity. Some examples:<p><pre><code> - 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&#x27;d be lying if you said you didn&#x27;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. </code></pre> Negativity abounds. It&#x27;s a wonder that all of our mental states aren&#x27;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:<p><pre><code> - 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 &quot;Discussions&quot; page recently, frequently containing a &quot;Show and Tell&quot; category [1], helping open source maintainers see their hard work in action. - Gamification and badge awarding has been explored [2], although it&#x27;s non-trivial to introduce (and if there&#x27;s talent disparity on a team, leaderboards and badges could actually be demoralizing and counter-productive) </code></pre> &gt; Note: While ideas like <i>go out for beers with the team once in a while</i> is helpful, I&#x27;d say that&#x27;s more of a social band-aid. I&#x27;d like to focus the conversation on the engineering process specifically.<p>[0] https:&#x2F;&#x2F;about.gitlab.com&#x2F;releases&#x2F;2021&#x2F;01&#x2F;22&#x2F;gitlab-13-8-released&#x2F;<p>[1] https:&#x2F;&#x2F;github.com&#x2F;laravel&#x2F;framework&#x2F;discussions&#x2F;categories&#x2F;show-and-tell<p>[2] https:&#x2F;&#x2F;www.dalsat.me&#x2F;download&#x2F;publications&#x2F;saner2017.pdf&amp;sa=U&amp;ved=2ahUKEwiluunw6fjuAhVgJzQIHWLQDQsQFjAAegQIAxAB&amp;usg=AOvVaw1yAwqK5Vjml9jXFR7Bhxk0

2 comments

PragmaticPulpabout 4 years ago
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.<p>The only sustainable solution I&#x27;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&#x27;t tolerate negativity.<p>&gt; Code review is important, but it is a necessarily a critique<p>Code review is only negative if you frame it as such, or allow the team to frame it as such.<p>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.<p>This is where positive leaders are essential: If your leaders are introducing code review as &quot;Yeah, it sucks to get your code torn apart...&quot; 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 &quot;Code review is a great way to get feedback, get some more eyes on your code, hone your skills, show others what you&#x27;re doing, and spread understanding of your domain&quot; then people tend to start to like it.
评论 #26205824 未加载
asplakeabout 4 years ago
Can’t beat the kinds of feedback that reinforce meaning in relation to needs, outcomes, purpose etc. When “done” is someone’s need met.