5 ms·

Pretty early on it calls code & design reviews "overhead", with "The Man" underneath. Maybe I'm missing some context/voiceover here, but every decent coder/des

Pretty early on it calls code & design reviews "overhead", with "The Man" underneath. Maybe I'm missing some context/voiceover here, but every decent coder/designer I've worked with embraces feedback & reviews. Not sure how I'd survive without them.

codewright 14y ago
Design reviews were big at my last company partly because the designer was DYING for feedback.
potatolicious 14y ago
Ditto here, though I think there might be a subtext to it. A few weeks ago there was a discussion on HN about the idiocy (or not) of standups. It turns out that a lot of people who dislike standups have very regimental ones, where it's underlings reporting to the boss, and there's an uncomfortable hierarchy to it. I've been one company before where code reviews and design reviews felt very much like this - it was less about peer feedback and more about progress monitoring, and there's a tinge of "you're being assessed" at every turn. This may be what the deck is referring to as "The Man". Right now I have a pretty sweet gig - the best company I've ever worked for by a long shot, and code reviews, design reviews, etc, feel like a critical part of a collaborative process rather than an onerous and sometimes politics-filled chore.
hkmurakami 14y ago
The traditional "annual review" where it's more like a "what did you not do perfectly so that I can dock you on your bonus" is not a pleasant experience.
- jwilliams 14y ago
  Don't disagree -- but in this context, the content (brief as it is) directly refers to code & design reviews.
milkbikis 14y ago
I think he's trying to depict the situation where one person becomes the go to guy for some component of the code, so everyone goes to him for code reviews etc. I vaguely remember Zach mentioning this in a talk he gave recently.
nahname 14y ago
I've never worked anywhere that code reviews were more effective than communication (ideally pairing). The process feels like a kludge to try and solve code quality. Rather than fix the problem (code quality going in and communication about changes) you place a barrier to entry for submitting code. Anything that prevents me from doing my job (shipping code) is going to cost the company money. Good quality staff, pairing and making sure test automating is in place are way better practices than code reviews.
- anthonyb 14y ago
  Well, in the places where I've seen it done right, the code reviews happen before the code is committed. Fixing existing code after it's already in the code base is a losing battle (particularly since it usually has to be re-tested), and you'll get pulled off onto "more important work". And it's not a kludge, it's a very good way of improving code quality (possibly up to the union of your better programmers' skills) and preventing dodgy crap from seeing the light of day. > Anything that prevents me from doing my job (shipping code) is going to cost the company money. I think you meant "working code" there - where "working" means "solves business problems" as wells as "not buggy" ;)
  - damncabbage 14y ago
    Well, in the places where I've seen it done right, the code reviews happen before the code is committed. Do you mean before the code is merged? Either programmers at these places worked directly together (eg. pairing), or they weren't using a DVCS like Git or HG. We use GitHub at work, with code-reviewed Pull Requests. You do you work (pairing as you want), then ask for it to be merged. It gets reviewed by at least one peer, and you get feedback, discuss and make changes, and then merge those into trunk. You get the benefit of code review, while also being allowed to carry on with something else in the same codebase without sitting on your butt waiting for a code review. (Has anyone else tried this and had good or bad results?)
    - jwilliams 14y ago
      Yup. That's exactly what we do here too. Good results and a noticeable increase in quality.

codewright 14y ago

Design reviews were big at my last company partly because the designer was DYING for feedback.

potatolicious 14y ago

Ditto here, though I think there might be a subtext to it. A few weeks ago there was a discussion on HN about the idiocy (or not) of standups. It turns out that a lot of people who dislike standups have very regimental ones, where it's underlings reporting to the boss, and there's an uncomfortable hierarchy to it. I've been one company before where code reviews and design reviews felt very much like this - it was less about peer feedback and more about progress monitoring, and there's a tinge of "you're being assessed" at every turn. This may be what the deck is referring to as "The Man". Right now I have a pretty sweet gig - the best company I've ever worked for by a long shot, and code reviews, design reviews, etc, feel like a critical part of a collaborative process rather than an onerous and sometimes politics-filled chore.

hkmurakami 14y ago

The traditional "annual review" where it's more like a "what did you not do perfectly so that I can dock you on your bonus" is not a pleasant experience.

jwilliams 14y ago
Don't disagree -- but in this context, the content (brief as it is) directly refers to code & design reviews.

milkbikis 14y ago

I think he's trying to depict the situation where one person becomes the go to guy for some component of the code, so everyone goes to him for code reviews etc. I vaguely remember Zach mentioning this in a talk he gave recently.

nahname 14y ago

I've never worked anywhere that code reviews were more effective than communication (ideally pairing). The process feels like a kludge to try and solve code quality. Rather than fix the problem (code quality going in and communication about changes) you place a barrier to entry for submitting code. Anything that prevents me from doing my job (shipping code) is going to cost the company money. Good quality staff, pairing and making sure test automating is in place are way better practices than code reviews.

anthonyb 14y ago
Well, in the places where I've seen it done right, the code reviews happen before the code is committed. Fixing existing code after it's already in the code base is a losing battle (particularly since it usually has to be re-tested), and you'll get pulled off onto "more important work". And it's not a kludge, it's a very good way of improving code quality (possibly up to the union of your better programmers' skills) and preventing dodgy crap from seeing the light of day. > Anything that prevents me from doing my job (shipping code) is going to cost the company money. I think you meant "working code" there - where "working" means "solves business problems" as wells as "not buggy" ;)
- damncabbage 14y ago
  Well, in the places where I've seen it done right, the code reviews happen before the code is committed. Do you mean before the code is merged? Either programmers at these places worked directly together (eg. pairing), or they weren't using a DVCS like Git or HG. We use GitHub at work, with code-reviewed Pull Requests. You do you work (pairing as you want), then ask for it to be merged. It gets reviewed by at least one peer, and you get feedback, discuss and make changes, and then merge those into trunk. You get the benefit of code review, while also being allowed to carry on with something else in the same codebase without sitting on your butt waiting for a code review. (Has anyone else tried this and had good or bad results?)
  - jwilliams 14y ago
    Yup. That's exactly what we do here too. Good results and a noticeable increase in quality.