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.
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.
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.
Good quality staff, pairing and making sure test automating is in place are way better practices than code reviews.
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" ;)
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?)