7 ms·

> code reviews aren't a rubber stamp I still remember my first "real" job. The team was on TFS and my code was basically if (condition) { if (same conditio

by mcny 6y ago

> code reviews aren't a rubber stamp I still remember my first "real" job. The team was on TFS and my code was basically if (condition) { if (same condition) { // do something } } and a senior developer laughed and said mcny is testing whether we actually look at the code and not just rubber stamp his changes. It was actually an honest mistake. At the same place though, we had F5 load balancers and actual integration with AS/400 systems but development/test environments didn't have a load balancer in front of them :(

yjftsjthsd-h 6y ago
> At the same place though, we had F5 load balancers and actual integration with AS/400 systems but development/test environments didn't have a load balancer in front of them :( That sucks; I really wish people would make a better effort at staging-production parity. Like, it's one thing to run dev on a smaller cluster or older hardware (although still potentially risky!), but changing out things like how connections are passed to the environment seems like asking for incompatible changes to get pushed through and break prod.
- WrtCdEvrydy 6y ago
  But how will our developers unlock a sense of pride and accomplishment if they can't rely on the underlying infrastructure to be consistent between PROD and QA...
- dijit 6y ago
  >That sucks; I really wish people would make a better effort at staging-production parity. Like, it's one thing to run dev on a smaller cluster or older hardware ( I can't speak for everybody, but, honestly I've always fought for parity of dev and prod; usually it comes down to cost though. If infrastructure is 10% of the operating budget of something and you need a dev environment for every team (or, ever dev!) then that cost is going to explode.
Cthulhu_ 6y ago
> testing whether we actually look at the code and not just rubber stamp his changes I've actually put in some er, "brown M&Ms" in my code before sending it off to review, because I was sure the people reviewing my code were like "oh, he wrote it so it's probably good". I think what would've helped in that case would be anonymized code reviews & comments, where the names of the author / commenters only pops up after it has been approved & merged. Actually I think that should be a feature everywhere, e.g. in Github issues. That way it becomes harder to judge e.g. comments / issues / commits based on the person who made it. Pseudonyms are nice, but you still build up a 'reputation' over time. But it'll probably have to be an opt-in option per user.

by mcny 6y ago

yjftsjthsd-h 6y ago

> At the same place though, we had F5 load balancers and actual integration with AS/400 systems but development/test environments didn't have a load balancer in front of them :( That sucks; I really wish people would make a better effort at staging-production parity. Like, it's one thing to run dev on a smaller cluster or older hardware (although still potentially risky!), but changing out things like how connections are passed to the environment seems like asking for incompatible changes to get pushed through and break prod.

WrtCdEvrydy 6y ago
But how will our developers unlock a sense of pride and accomplishment if they can't rely on the underlying infrastructure to be consistent between PROD and QA...
dijit 6y ago
>That sucks; I really wish people would make a better effort at staging-production parity. Like, it's one thing to run dev on a smaller cluster or older hardware ( I can't speak for everybody, but, honestly I've always fought for parity of dev and prod; usually it comes down to cost though. If infrastructure is 10% of the operating budget of something and you need a dev environment for every team (or, ever dev!) then that cost is going to explode.

Cthulhu_ 6y ago

> testing whether we actually look at the code and not just rubber stamp his changes I've actually put in some er, "brown M&Ms" in my code before sending it off to review, because I was sure the people reviewing my code were like "oh, he wrote it so it's probably good". I think what would've helped in that case would be anonymized code reviews & comments, where the names of the author / commenters only pops up after it has been approved & merged. Actually I think that should be a feature everywhere, e.g. in Github issues. That way it becomes harder to judge e.g. comments / issues / commits based on the person who made it. Pseudonyms are nice, but you still build up a 'reputation' over time. But it'll probably have to be an opt-in option per user.