Return to Answer

What I didn't hear you mention was peer reviews.

You did say 'we' a lot. So I assume this is a team. The best use of a team is to check that you're not simply deluding yourself about how awesome you are.

Peer review production code. Peer review test code. The best way to see if you have written readable code is to have someone else read it. Let's do better then just keeping the CPU happy.

Also, you seem almost too enthusiastic about code quality. While code quality is certainly a good thing, it's easy to do bad things in it's name. Guard against this by sanity checking. Watch out for tests that take time to create but don't really help you find defects any faster. Watch out for tests that impose a structure on your code (perhaps by digging behind abstractions) and make refactoring harder.

Don't depend too highly on analysis tools either. I'll take the subjective but considered opinion of a human reviewer over what some tools says about readability any day. Use the tools to remind you of things to consider. Do not worship them as gods. They are good tools but poor masters.

And above all. Don't forget that the point is to get a job done.

Regarding your hot fix edit, when time is critical you can avoid time eating formal peer reviews by peer checking and pair programming. Two people sitting at one keyboard can accomplish a lot. (It's tough with covid still running around. Please get vaccinated). When you can't truly pair program then grab someone as soon as you have working code to show off and get their eyes on it. Let them sit in your chair and get their input. That's a peer check.

Even if the place is on fire there's still time to move safely.

What I didn't hear you mention was peer reviews.

You did say 'we' a lot. So I assume this is a team. The best use of a team is to check that you're not simply deluding yourself about how awesome you are.

Peer review production code. Peer review test code. The best way to see if you have written readable code is to have someone else read it. Let's do better then just keeping the CPU happy.

Also, you seem almost too enthusiastic about code quality. While code quality is certainly a good thing, it's easy to do bad things in it's name. Guard against this by sanity checking. Watch out for tests that take time to create but don't really help you find defects any faster. Watch out for tests that impose a structure on your code (perhaps by digging behind abstractions) and make refactoring harder.

Don't depend too highly on analysis tools either. I'll take the subjective but considered opinion of a human reviewer over what some tool says about readability any day. Use the tools to remind you of things to consider. Do not worship them as gods. They are good tools but poor masters.

And above all. Don't forget that the point is to get a job done.

————

Regarding your hot fix edit, when time is critical you can avoid time eating formal peer reviews by peer checking and pair programming. Two people sitting at one keyboard can accomplish a lot. (It's tough with covid still running around. Please get vaccinated). When you can't truly pair program then grab someone as soon as you have working code to show off and get their eyes on it. Let them sit in your chair and get their input. That's a peer check.

Even if the place is on fire there's still time to move safely.

What I didn't hear you mention was peer reviews.

You did say 'we' a lot. So I assume this is a team. The best use of a team is to check that you're not simply deluding yourself about how awesome you are.

Peer review production code. Peer review test code. The best way to see if you have written readable code is to have someone else read it. Let's do better then just keeping the CPU happy.

Also, you seem almost too enthusiastic about code quality. While code quality is certainly a good thing, it's easy to do bad things in it's name. Guard against this by sanity checking. Watch out for tests that take time to create but don't really help you find defects any faster. Watch out for tests that impose a structure on your code (perhaps by digging behind abstractions) and make refactoring harder.

Don't depend too highly on analysis tools either. I'll take the subjective but considered opinion of a human reviewer over what some tools says about readability any day. Use the tools to remind you of things to consider. Do not worship them as gods. They are good tools but poor masters.

And above all. Don't forget that the point is to get a job done.

Regarding your hot fix edit, when time is critical you can avoid time eating formal peer reviews by spot checking and pair programming. Two people sitting at one keyboard can accomplish a lot. (It's tough with covid still running around. Please get vaccinated). When you can't truly pair program then grab someone as soon as you have working code to show off and get their eyes on it. Let them sit in your chair and get their input. That's a spot check.

Even if the place is on fire there's still time to move safely.

What I didn't hear you mention was peer reviews.

You did say 'we' a lot. So I assume this is a team. The best use of a team is to check that you're not simply deluding yourself about how awesome you are.

Peer review production code. Peer review test code. The best way to see if you have written readable code is to have someone else read it. Let's do better then just keeping the CPU happy.

Also, you seem almost too enthusiastic about code quality. While code quality is certainly a good thing, it's easy to do bad things in it's name. Guard against this by sanity checking. Watch out for tests that take time to create but don't really help you find defects any faster. Watch out for tests that impose a structure on your code (perhaps by digging behind abstractions) and make refactoring harder.

Don't depend too highly on analysis tools either. I'll take the subjective but considered opinion of a human reviewer over what some tools says about readability any day. Use the tools to remind you of things to consider. Do not worship them as gods. They are good tools but poor masters.

And above all. Don't forget that the point is to get a job done.

Regarding your hot fix edit, when time is critical you can avoid time eating formal peer reviews by peer checking and pair programming. Two people sitting at one keyboard can accomplish a lot. (It's tough with covid still running around. Please get vaccinated). When you can't truly pair program then grab someone as soon as you have working code to show off and get their eyes on it. Let them sit in your chair and get their input. That's a peer check.

Even if the place is on fire there's still time to move safely.

What I didn't hear you mention was peer reviews.

You did say 'we' a lot. So I assume this is a team. The best use of a team is to check that you're not simply deluding yourself about how awesome you are.

Peer review production code. Peer review test code. The best way to see if you have written readable code is to have someone else read it. Let's do better then just keeping the CPU happy.

Also, you seem almost too enthusiastic about code quality. While code quality is certainly a good thing, it's easy to do bad things in it's name. Guard against this by sanity checking. Watch out for tests that take time to create but don't really help you find defects any faster. Watch out for tests that impose a structure on your code (perhaps by digging behind abstractions) and make refactoring harder.

Don't depend too highly on analysis tools either. I'll take the subjective but considered opinion of a human reviewer over what some tools says about readability any day. Use the tools to remind you of things to consider. Do not worship them as gods. They are good tools but poor masters.

And above all. Don't forget that the point is to get a job done.

What I didn't hear you mention was peer reviews.

You did say 'we' a lot. So I assume this is a team. The best use of a team is to check that you're not simply deluding yourself about how awesome you are.

Peer review production code. Peer review test code. The best way to see if you have written readable code is to have someone else read it. Let's do better then just keeping the CPU happy.

Also, you seem almost too enthusiastic about code quality. While code quality is certainly a good thing, it's easy to do bad things in it's name. Guard against this by sanity checking. Watch out for tests that take time to create but don't really help you find defects any faster. Watch out for tests that impose a structure on your code (perhaps by digging behind abstractions) and make refactoring harder.

Don't depend too highly on analysis tools either. I'll take the subjective but considered opinion of a human reviewer over what some tools says about readability any day. Use the tools to remind you of things to consider. Do not worship them as gods. They are good tools but poor masters.

And above all. Don't forget that the point is to get a job done.

Regarding your hot fix edit, when time is critical you can avoid time eating formal peer reviews by spot checking and pair programming. Two people sitting at one keyboard can accomplish a lot. (It's tough with covid still running around. Please get vaccinated). When you can't truly pair program then grab someone as soon as you have working code to show off and get their eyes on it. Let them sit in your chair and get their input. That's a spot check.

Even if the place is on fire there's still time to move safely.