I ruin developers’ lives with my code reviews and I'm sorry

There's something to be said for "Marine Drill Instructor" responses.

When the DI is screaming profanities at recruits, [s]he is preemptively saving their lives. The manner in which it is done, is actually a component of the training. A significant part of military training, is to deprecate the individual, in favor of the team. The DI is not an individual. They are the sharp end of the elite organization that the recruit hopes to join. The variable is the recruit. The organization is a hardcoded constant.

But most of the world is not in the military.

I understand Linus' expletive-laden rants. I don't like them, and I think he could probably find other ways to enforce Quality, but he does get results. The same for Steve Jobs, and his infamous diatribes. When I worked for a Japanese company, I watched managers literally bring employees to tears, with simple, quiet comments. I worked for a British company, and got experience with the sarcasm-fueled way that British managers work.

As a manager, I worked with firm kindness. I made it clear what was expected as an end result, and did my best to support my employees. It seemed to work for my team, but I also had a particular type of team. My style probably would not have worked in other contexts. I feel that I projected a gestalt, as opposed to a set of individual orders. We acted as a unit; which wasn't easy, as I also worked to preserve the individuality of the members.

As a coder, I am fairly obsessive about Quality. Code quality, documentation quality, design quality, process quality, schedule quality, and end-result quality.

I'm very hard on myself. I set a high bar, and usually meet it.

I've learned not to project it onto others; if at all possible. I understand that my level of Quality is probably not something most companies would consider "cost-effective."

Here's an example: I am writing an app with a screen that displays a big map, and has overlaid views and controls. I spent at least 45 minutes, today, ensuring that one of the controls aligns pixel-perfect with its "alter ego" in the "unfurled" HUD display. It was a pain. I had to set a measurement point in the simulator, run the animation, then review the open display, and make sure they matched. Then, I had to rotate the device, and do the same.

Many, many developers would say "5 or six pixels off; good enough. It's all under a fat finger, anyway." I am not right in the head, though. That kind of thing actually makes me physically uncomfortable. For me, that needs to be 0 pixels; even if it is under a fingertip.

So I will do it for my work. If I find that I can't use the work of others, I won't work with them. I'm very, very picky about dependencies. Fancy Web sites and eye-candy aren't particularly indicative of decent work. Sadly, large user communities no longer seem to be a mark of quality, either. I can't take anyone at their word. I have to test for myself. I have been fortunate to find teams of like-minded folks, but they are rare.

But I won't tear people apart, and I won't lob public insults. I feel that is not helpful. If the only way that I can feel good about myself, is to tear down others, I need to do some work on myself; maybe with a psychotherapist.

From 2019. Previous discussion:

https://news.ycombinator.com/item?id=19190472 - 155 comments

> If a guy brings me his code, and it has mistakes, it brings insane pleasure from how smart I feel. [...] And if you tell me that you haven't had this feeling ever, then you're lying. Tell me about higher goals, training rookies and all that - I know you're simply too full of themselves. And if you try to tell me that you learned to defeat that feeling (however it manifests in you), then I must be a pink unicorn.

This has to either be a cultural thing or satire.

> Honestly, I’m not sure all of them are experienced enough to give a useful critique

I wouldn't let this be a stumbling block to asking for more review. I think it's like writing an article or paper - once you've invested a lot of time into the thing it gets harder to see the warts. Having another set of eyes can really help catch that stuff, even if they aren't at the same level of expertise as you. Back in my research days the department I was in had a person who's job was basically reading research papers and providing feedback - in this case she usually focused on the paper structure, clarity of phrasing, and of course grammar - she was an expert in writing not in CS. Yet looking back a drafts of papers before and after she had given input shows a massive improvement, even if the technical content was unchanged. Similarly a smart intern can be a great source of input for making my code clearer and better, even if the algorithm doesn't fundamentally change.

Also, if like me you are prone to falling into ego traps, inexperienced folks can bypass the ego's defenses. A simple "hey why did you do it $complicated_way instead of $simple_way?" can hit a lot harder than "hey make this $simple_way" from a mentor. I think it's because I've invested time into teaching the intern and when they ask a good question like that my ego gets a boost from "I taught that kid well" to balance out the "OMG YOU THINK I'M TERRIBLE AT THIS LETS FIGHT" response. (It may also be tempered because I tend to view the intern's questions as genuine requests for input, so I start thinking of the explanation and realize $simple_way will in fact work just fine.)

The process is hated by those who do it good and loved by those who get to feel superior- by the physics of work, the process filters for asshats.