11–20 of 271 posts
After reading the article, I feel like a code test and discussion and or whiteboard would have filtered the type of developer they mentioned who is a net negative on the code base.
This is a good counter-argumnent to the frequent article decrying whiteboard tests.
Maybe these developers that produce "negative work" think your code sucks. Ever consider that?
Or maybe you're responding to something OP didn't write. It's hard to tell. Perhaps you'll elaborate.
There's this magical process called continuous integration that internalizes the impact of bad (or, more likely, misguided) developers. Don't let them merge their branch until all tests pass. If their commit breaks something while all tests still pass, then direct them to write the missing tests.
CI does nothing to prevent bad developers checking in bad code. You just end up with equally poor unit tests.
Earlier quoted context omitted.
This is a good counter-argumnent to the frequent article decrying whiteboard tests.
I feel like whiteboarding is really essential when talking about how code should be written, but most whiteboard tests are about writing code on the whiteboard. There's a big difference between the two activities.
There's this magical process called continuous integration that internalizes the impact of bad (or, more likely, misguided) developers. Don't let them merge their branch until all tests pass. If their commit breaks something while all tests still pass, then direct them to write the missing tests.
Sometimes they are in politically privileged positions and you can't get rid of them, ask me how I know.
And the context implies those were the only 2 changes/check-ins. Seems odd that nobody questioned the low output.
Maybe these developers that produce "negative work" think your code sucks. Ever consider that?
So what? Is that a justification for producing bad code?
There's this magical process called continuous integration that internalizes the impact of bad (or, more likely, misguided) developers. Don't let them merge their branch until all tests pass. If their commit breaks something while all tests still pass, then direct them to write the missing tests.
Sometimes they are in politically privileged positions and you can't get rid of them, ask me how I know.
There's this magical process called continuous integration that internalizes the impact of bad (or, more likely, misguided) developers. Don't let them merge their branch until all tests pass. If their commit breaks something while all tests still pass, then direct them to write the missing tests.
CI does nothing to prevent bad developers checking in bad code. You just end up with equally poor unit tests.
It's not perfect, but it's better than most of the alternatives, and perfect isn't actually on the table anyhow.