Cover Your Ass Folder - If you need one of these, you need to quit. If there are issues, man up and get them resolved. Don't just hide away the details until some big angry manager knocks on your door.
Need to Brag - Work for a company that does code reviews/inspection. It's a) great for the quality of the code and b) great for assigning merit to the people who've earned it, do that.
What do you do when your team thinks code reviews are not worth the time they take for a majority of the commits?
At my previous job, code reviews were required foreverything more complicated than a CSS tweak: change the DOM significantly, and a UI dev has to Ok it. Change a piece of JS, and the UI definitely needs to ok it. Change a piece of the mid-tier, and you can bet your ass that it's vetted before it's comitted - often by additional developers that don't even work on the mid tier.
Granted, this was a corporate b2b app for a fairly large company. Everything needed to be vetted, and sometimes it splled delays (hey, can you do my code review so I can test on staging? Ok, in 15 minutes then..).
At my current position on a small team, we do optional weekly code reviews: do something interesting or that you want feedback on, bring it up in the weekly.
How do you make pre-commit vetting of code quality scale, especially on a low headcount, high velocity team?
Without impacting the weekly velocity numbers that people not involved in said code reviews are used to seeing?
How do you make pre-commit vetting of code quality scale, especially on a low headcount, high velocity team?
Make sure to hire only top notch. Vetting goes faster when everybody knows what they are doing (yes, this is sort of a "duh!").
Without impacting the weekly velocity numbers that people not involved in said code reviews are used to seeing?
No idea what "weekly velocity" is or who is making that number up in your company but I suggest to start measuring in months and quarters for a tangible idea of effectiveness. Forest, Trees.
high-quality man hours ... expected to actually produce
So, a bit like these velocity points in Pivotal Tracker, only... even more detached from reality?
I'll let you in on why measuring mostly anything related to code in weeks is wrong: It promotes short-term thinking and code debt, not unlike what we have seen in the banking blowup.
Yes, there are classes of tasks that can be solved in a week-timeframe. But those are not normally the ones that make or break your project.
For a small, contrived example: You can hire a low-skilled worker to provision new servers. You can then measure how many servers that person gets done per week.
Or you can hire a high-skilled worker to build infrastructure for provisioning servers with a mouseclick.
This will take months. But once finished you have saved yourself an ongoing full-time salary and can assign the high-skilled worker to other tasks.
Good luck determining that high-skilled workers "weekly velocity", though...
Need to Brag - Work for a company that does code reviews/inspection. It's a) great for the quality of the code and b) great for assigning merit to the people who've earned it, do that.