4 ms·

There's a certain tone in this article that bothers me a bit. At least in software engineering, the idea of reviews is to find errors in code or design how eve

There's a certain tone in this article that bothers me a bit. At least in software engineering, the idea of reviews is to find errors in code or design how ever small they are. When inspecting any code, we almost always find at least something, regardless of the level of quality. It's not about being fair, it's not personal, and it probably isn't even dependent on the reviewers personality. It's just that when the goal is to find deviations, that's what happens. It's just a process. The errors may be small or big, it doesn't matter, we just need to find them. Some inexperienced developers often find the code review process intimidating and unfair. They take it personally. That's a wrong attitude.

kevinskii 12y ago
About a year ago I had the misfortune of working with a program manager. He asked me to create a PowerPoint presentation on something totally unimportant and irrelevant. After failing to explain this to him, I decided to accommodate him figuring that he would become more reasonable once he knew a bit more. After emailing him the presentation, he called and asked me to switch the 2nd and 3rd bullet on one of the slides and then send him the revision. Our relationship went downhill from there. Finally I had no choice but to marginalize him. I don't think the author of the article had code reviews in mind; she's alluding to this sort of nonsense when you sense her negative tone.
- kyberias 12y ago
  You're probably right she didn't have code reviews in mind. Perhaps I was just worried that someone takes this as an example and will do some crazy unnecessary tricks in software. Also, I don't have any experience of such absurd situations despite my experience working with dozens of teams. Maybe that's because I'm from Northern Europe where professionals don't take such bullshit from anyone. Oops... perhaps slightly strong wording. Well, I guess you get the point.
stefs 12y ago
it's real. it usually happens when i working on mobile apps for big companies. apps are comparably new (compared to websites, desktop apps or server software) and for a lot of customers these are the first apps they launch. so new and exciting! they want to be part of it, they have to be part of it. another reason is they're afraid of getting downsized if they're not working on (contributing to) N projects at once. on a technical level they don't have to add anything to it, so it's mostly visual tweaks they're demanding; usually something they've seen in other apps (no matter if it was something that made sense on ios in a different context and we're working on android). that's called bikeshedding. if the project bombs they didn't really have anything to do with it (apart from that one minor change) - if it's a success they were an integral part of the team. one project, we needed a notification sound. the product owner begged us to keep our mouths shut, take one of the default notification sound files and tell the others custom sounds aren't possible - because if the marketing department got wind of it we'd have to test a boatload of different files for different managers and wait another month for the notification-sound-committees final decision.

kevinskii 12y ago

About a year ago I had the misfortune of working with a program manager. He asked me to create a PowerPoint presentation on something totally unimportant and irrelevant. After failing to explain this to him, I decided to accommodate him figuring that he would become more reasonable once he knew a bit more. After emailing him the presentation, he called and asked me to switch the 2nd and 3rd bullet on one of the slides and then send him the revision. Our relationship went downhill from there. Finally I had no choice but to marginalize him. I don't think the author of the article had code reviews in mind; she's alluding to this sort of nonsense when you sense her negative tone.

kyberias 12y ago
You're probably right she didn't have code reviews in mind. Perhaps I was just worried that someone takes this as an example and will do some crazy unnecessary tricks in software. Also, I don't have any experience of such absurd situations despite my experience working with dozens of teams. Maybe that's because I'm from Northern Europe where professionals don't take such bullshit from anyone. Oops... perhaps slightly strong wording. Well, I guess you get the point.

stefs 12y ago

it's real. it usually happens when i working on mobile apps for big companies. apps are comparably new (compared to websites, desktop apps or server software) and for a lot of customers these are the first apps they launch. so new and exciting! they want to be part of it, they have to be part of it. another reason is they're afraid of getting downsized if they're not working on (contributing to) N projects at once. on a technical level they don't have to add anything to it, so it's mostly visual tweaks they're demanding; usually something they've seen in other apps (no matter if it was something that made sense on ios in a different context and we're working on android). that's called bikeshedding. if the project bombs they didn't really have anything to do with it (apart from that one minor change) - if it's a success they were an integral part of the team. one project, we needed a notification sound. the product owner begged us to keep our mouths shut, take one of the default notification sound files and tell the others custom sounds aren't possible - because if the marketing department got wind of it we'd have to test a boatload of different files for different managers and wait another month for the notification-sound-committees final decision.