- If this post is satire, it's hilarious and spot-on!

- If this is real, quit while you can, and may god have mercy on your soul.

- The fact that it's difficult to tell if it'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't ever be interm rules. They should be a linter auto-fix rule that applies it to diffs automatically and NOTHING ELSE. It shouldn't even blip at you saying it's against style, it should just fix it.

If you don't have this, you waste everyone's brain cycles with your pedantic import ordering rule or similar on both sides and it'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.

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

Also, great negative PR for this company. This sort of discussion would also come off as much less arrogant/snarky face-to-face.

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

Translation: "We have extremely strong opinions on what materials to use for our nuclear power plant's bike shed."

https://en.wikipedia.org/wiki/Law_of_triviality

There'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/are the lines < 80 characters/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 "ruthlessness" was brought up as a negativism. I countered that (or so I thought) with the following question to the rest of the coder team: "Do you want me to point out problems I perceive with the code / approach / whatever, or do you want me to hold back in order to be considerate of someone". To my surprise, in the presence of management, the unanimous answer was to show consideration!

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.

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's known that you don't take PR comments personally, they're just feedback. And the more critical the feedback, the better developer you become.

The whole "we are so cool because we are ruthless. Merciless, I tell you! Once you get through our code review your code will be perfect." 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.

I personally would strongly prefer if they put it in milder technical terms, "We are very conservative with deviations from our preferred code style and conventions". I suppose that wouldn'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 "ruthlessness" is a red flag, similar to ninja buzzword.

Strictness in one direction does not mean company is strict at all fronts. Code reviews can be used without automated tests or version control.

In this case the review process seems like a "busy work". 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)

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

God, how insufferable. "Our code reviews are so ruthless because our clients (and by extension, us) are so much better than everyone else!" But apparently we can't write a bot or a pre-commit hook to re-order imports so instead we'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't worry, we'll write a 2 page email to explain this jargon.

I guess that's one way of doing it, but you're dependent on the quality of said ruthless reviewers, and delivery of the message is separate from the message itself. Personally, I'm more of a "kill them with kindness" guy, so while my reviews would come off as soft by the article's definition, I'd argue that they'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't necessarily negate.

If it'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 "ruthless".

This reminds me of people who say, "People don't like me because I'm so honest." No, people don't like you because you lack basic empathy.

Code reviews are pretty heavy going on the project I'm working on at the moment. The code isn'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's a really good idea not to be an asshole because it'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't blame them. Employers deserve no loyalty in the US these days because they don't give any.

'We are rigorous on code reviews' would be a better approach. We don't have to be jerks to make sure that code is up to standards.

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

An awful lot of companies can describe their customers in such terms. Microsoft can, Google can, Pepsi and Bic can.

Satire, yes?

If not, GTFO while you can.

As a PHP "shop" this is why we use StyleCI [1].

Our code isn't that critical, the quality and maintainability are. We don't waste time on "code reviews" that only check the style of code, that can be automated away.

Yes, I make StyleCI, but we use it in the place I work too (unrelated).

[1] https://styleci.io

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's probably a joke but it'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.

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've got time to dream up ways to be witty in order to be snarky to a co-worker, then you've got too much time on your hands at work and clearly need to fill it with other responsibilities.

There is another side to this. I've seen a ton of technical criticism get delivered with emotionally laden commentary. X is "totally broken", "crap", "not even wrong", "just wrong", "terrible", etc. There is a way to deliver criticism while maintaining an environment of common professional respect. Many people don't even try. With the caveat that I'm painting with a culturally biased brush, I've found Germans (and Finns!) to be particularly abrasive in this regards.

I'm glad you wrote this because I would definitely never consider a person with such an obtuse attitude for any position

It's not about sensitivity it's about not being a inconsiderate pedant

I'm also sure that a lot of your critique has no basis in technical quality rather than personal preferences. This is what I see time and time again with the people that "worry most" about the code (but when it's their code that's critiqued it's full of problems). Uncle Bob fans, "code craftsmen" all those people make my BS detector beep

There are also people that pick a lot of "problems" in the code that ignore glaring issues in other areas/code they wrote/other aspects of the issue, including further code maintainability, readability (no, being readable to you does not mean it's readable by somebody else), etc

It's not so much about bruised egos rather than wasting company time with pedantic nitpicking, not trusting colleagues (which is fundamental and you seem to be utterly incapable of), overstating your own importance in the team (unless you really picked a company full of bozos, which in the end is your mistake again)

It's not what you say it's the way that you say it.

If you don't have the social acumen to know how to raise issues and to discuss them reasonably (i.e. without rubbing people up the wrong way), then yes, erring on the side of being considerate is likely to win you more friends and help you keep your job longer.

There's a fine line between constructive feedback and being toxic to a team.

It is very difficult to do code reviews when beside the technical topics politics come into place. After 8h of reviews on 2000 lines of code finding 100 issues, it is almost not possible to be nice anymore. But hell starts when manager decide to give a GO because deadline approached without even fixing the 3 major bugs.

It's interesting that even your comment is getting down voted. I wonder if it's a millennial thing? It would be interesting to know the ages of the people here commenting on how "harsh" the post seems vs. "yeah that's great."

I read the post as going out of it's way to give praise while pointing out what the company requires (perhaps that is interpreted as patronizing). But many people here are commenting on how rude it is. Bizarre. If you think this is rude, you've never worked in a "tough" environment.

How would people here suggest communicating the same information? Is it just that it might be interpreted as patronizing that's the problem?

So they didn't ask you to point out the problems in a more considerate way?

Instead, they just asked you to stop pointing out the problems?

Were these problems nitpicks, personal preference (as some here are apparently assuming) or were they objectively technical issues?

Programming tends to attract a lot of people who are smart but too young to have wisdom. The kind of wisdom that tells one when it's worthwhile to be ruthless and when it's just pedantry, self-defeating, etc.

The kind of wisdom that keeps one from positing that the people who don't see things their way are delicate.

As a team, decide how much you care. Some teams won't care much at all, and will follow a "hey as long as it works" attitude. Other teams will be deeply interested in making their code as good as it could be, and will want comments about doing things more cleanly or elegantly and will view PR review as a chance to learn and improve.

As long as everyone's on the same page, and sharing the same attitude, that drive to improve will come across as a positive thing rather than a jerk move. But if you're the one person with that attitude on a team of good-enoughers, yeah, not so much.

Yeah I think this kind of thing is a teamwide preference. If you prefer very rigid styling and enforce a style checker, great – that can be put into a script which you compulsorily run before review.