We are ruthless on code reviews

- If this post is satire, it&#x27;s hilarious and spot-on!<p>- If this is real, quit while you can, and may god have mercy on your soul.<p>- The fact that it&#x27;s difficult to tell if it&#x27;s real or not says a lot about our industry.

If you have things in your style guide that can be done easily by a script, they shouldn&#x27;t ever be interm rules. They should be a linter auto-fix rule that applies it to diffs automatically and NOTHING ELSE. It shouldn&#x27;t even blip at you saying it&#x27;s against style, it should just fix it.<p>If you don&#x27;t have this, you waste everyone&#x27;s brain cycles with your pedantic import ordering rule or similar on both sides and it&#x27;s a red flag about the company to me.

I love working in environments like this. I can say hands down they were my most productive years as a programmer.<p>Quality code review is the single most important trait of a high performing senior programmer.

People find it acceptable to write more harshly than they&#x27;d speak face-to-face. I wonder if all 43 or whatever points would have come up if it was done side-by-side the developer.<p>Also, great negative PR for this company. This sort of discussion would also come off as much less arrogant&#x2F;snarky face-to-face.

&gt;I don’t mean we’re mean-spirited. I just mean that we are merciless. You’ll notice that I left the comment “Beep!” on the imports of every file you touched. What I meant was, “<i>Your imports violate our standard convention—we order them by built-ins, then third party, and then project level</i>,” but that was too much to type on every file.<p>Translation: &quot;We have <i>extremely</i> strong opinions on what materials to use for our nuclear power plant&#x27;s bike shed.&quot;<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Law_of_triviality" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Law_of_triviality</a><p>There&#x27;s seems to be an inverse relationship between how much effort a team spends on surface details of code (e.g. does it adhere to linting standards&#x2F;are the lines &lt; 80 characters&#x2F;imports ordered?) and how much time and effort a team spends on deeper architectural issues (loose coupling, de-duplication, un-reinventing the wheel, transforming imperative to declarative code, etc.)

It always astonished me how delicate coders in the UK are (I am from Germany, working in the UK currently). During a team meeting at a former company, my &quot;ruthlessness&quot; was brought up as a negativism. I countered that (or so I thought) with the following question to the rest of the coder team: &quot;Do you want me to point out problems I perceive with the code &#x2F; approach &#x2F; whatever, or do you want me to hold back in order to be considerate of someone&quot;. To my surprise, in the presence of management, the unanimous answer was to show consideration!<p>I think people who work together should be able to openly communicate with each other about technical issues. Sadly, most people are (either self-perceived or for real) not good enough to do that without bruised egos.

I miss working in an environment like this. I was actually surprised to find so much negative feedback in the comments.<p>I think a detail getting glossed over is that the tone needs to be calibrated to the relationships between team members. If team members joke around with each other, send silly gifs, get lunch or coffee together, and are generally on good terms with one another...then it&#x27;s known that you don&#x27;t take PR comments personally, they&#x27;re just feedback. And the more critical the feedback, the better developer you become.

The whole &quot;we are so cool because we are <i>ruthless</i>. <i>Merciless</i>, I tell you! Once you get through our code review your code will be perfect.&quot; attitude of this article is a bit surprising for one ranked so highly on HN. Do people really prefer this kind of attitude? Bender GIFs and snarky comments can become quickly tiring.<p>I personally would strongly prefer if they put it in milder technical terms, &quot;We are very conservative with deviations from our preferred code style and conventions&quot;. I suppose that wouldn&#x27;t be as click-baity, but for me (and I suspect a lot of other people) it would be easier to appreciate, since we understand that being conservative before accepting commits leads to a well-groomed codebase.

For me declaration of &quot;ruthlessness&quot; is a red flag, similar to ninja buzzword.<p>Strictness in one direction does not mean company is strict at all fronts. Code reviews can be used without automated tests or version control.<p>In this case the review process seems like a &quot;busy work&quot;. Checks bellow could be easily integrated into build script or CI. Such code should not even made it into code review. (I am not arguing about the rule itself, just how it should be enforced)<p>&gt; <i>You’ll notice that I left the comment “Beep!” on the imports of every file you touched. What I meant was, “Your imports violate our standard convention—we order them by built-ins, then third party, and then project level,” but that was too much to type on every file.</i>

God, how insufferable. &quot;Our code reviews are so ruthless because our clients (and by extension, us) are so much better than everyone else!&quot; But apparently we can&#x27;t write a bot or a pre-commit hook to re-order imports so instead we&#x27;ll write some non-sensical in-house jargon (because typing out the full explanation is too much effort, even though we are the best of the best because our clients are so excellent and demanding). But don&#x27;t worry, we&#x27;ll write a 2 page email to explain this jargon.

I guess that&#x27;s one way of doing it, but you&#x27;re dependent on the quality of said ruthless reviewers, and delivery of the message is separate from the message itself. Personally, I&#x27;m more of a &quot;kill them with kindness&quot; guy, so while my reviews would come off as soft by the article&#x27;s definition, I&#x27;d argue that they&#x27;re just as effective, and my teammates still want to have a beer with me at the end of the day, instead of walking away thinking I have a stick up my ass, which an email about ruthlessness wouldn&#x27;t necessarily negate.

If it&#x27;s anything like where I work, some people come in for more ruthlessness than others. Some are more equal than others, if you will. New people or those deemed unworthy will receive the full brunt of scrutiny, to the point of bare-faced pedantry. Those who are golden are given the benefit of the doubt. You can probably tell which one I am. It gets really old to see this time and again, and to see the team pat themselves on the back for being &quot;ruthless&quot;.

This reminds me of people who say, &quot;People don&#x27;t like me because I&#x27;m so honest.&quot; No, people don&#x27;t like you because you lack basic empathy.

Code reviews are pretty heavy going on the project I&#x27;m working on at the moment. The code isn&#x27;t noticeably better for it though!

Yet despite being assholes (ruthless in their parlance) who obviously have not on-boarded said employee or even told him what is expected of his code, I doubt their software has any less bugs than the software from shops who are not assholes (ruthless in their parlance). Sounds like a great reason to avoid working here and other places that have the same mentality. If you want your coworkers to actually do their work, it&#x27;s a really good idea not to be an asshole because it&#x27;s incredibly easy to get away with not doing shit in tech while seeming to do so and after awhile, most people will switch to that mode when berated long enough. I can&#x27;t blame them. Employers deserve no loyalty in the US these days because they don&#x27;t give any.

&#x27;We are <i>rigorous</i> on code reviews&#x27; would be a better approach. We don&#x27;t have to be jerks to make sure that code is up to standards.

&quot;One thing to keep in mind is that our customer base is unique. Our customers work for many of the most successful companies in their respective industries. They are where they are because they are committed to excellence and have great attention to detail.&quot;<p>An awful lot of companies can describe their customers in such terms. Microsoft can, Google can, Pepsi and Bic can.

Satire, yes?<p>If not, GTFO while you can.

As a PHP &quot;shop&quot; this is why we use StyleCI [1].<p>Our code isn&#x27;t that critical, the quality and maintainability are. We don&#x27;t waste time on &quot;code reviews&quot; that only check the style of code, that can be automated away.<p>Yes, I make StyleCI, but we use it in the place I work too (unrelated).<p>[1] <a href="https:&#x2F;&#x2F;styleci.io" rel="nofollow">https:&#x2F;&#x2F;styleci.io</a>

Based on this I can only assume that workiva builds spaceships or life support systems. You know, something where absolute perfection is far more important than having a fulfilling and constructive workplace environment.

It&#x27;s probably a joke but it&#x27;s backfiring because most comments are taking it seriously and thinking the place actually works like this.

Ugh, comes off as condescending, immature, and insufferable.<p>I do think strict code review and high standards are the way to go, but when implementing them it becomes all the more important to have appropriate and professional interpersonal communication and documented policies.

If you&#x27;ve got time to dream up ways to be witty in order to be snarky to a co-worker, then you&#x27;ve got too much time on your hands at work and clearly need to fill it with other responsibilities.