The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
FFS! How stupid can you get? They have been trying to stop the Irish drink driving and when it finally starts to work they come up with an idea like this? What a surprise that the "Yes" voters own pubs!
That's like saying "it's OK to drink and drive provided it's only a few miles, and you don't weave about too much". Idiots!
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
Griff, this isn't Ireland it's Kerry. A place where they call a man under a wheelbarrow an engineer.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DDEthel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
I don't actually think this is that stupid. You are extremely unlikely to have an accident pottering about on this type of road, and even if you are ten times more likely after two pints, that's still a negligible risk and in my opinion one worth taking for increased social interaction in rural areas.
This is currently de facto the case because drink driving is not enforced in rural areas – probably precisely because it causes very few accidents! But it would make more sense to have legal limits for what you're allowed to do rather than have an unclear tacit understanding of what's okay (which seems to be 'you aren't weaving about enough for anyone to report you').
Don't get me wrong - I like them in general. It's just that I spent one day implementing a feature and now three days and counting on the code review. At this point we aren't even discussing my changes, but the design of our unit-test system
So yeah, maybe you, like, are, you know, doing it wrong.
That's a definite possibility. I've only worked at one place that tried code reviews. Those sessions always broke down into hour long discussions about how the white spacing didn't *look* right or a variable should have been named differently. Any bugs saved in those sessions were entirely imaginary. Your mileage may vary.
Those sessions always broke down into hour long discussions about how the white
spacing didn't *look* right or a variable should have been named differently.
Any bugs saved in those sessions were entirely imaginary
Which represents a process failure at that location.
Process failures can impact software development and even other types of processes at a company in many negative ways.
That however is due to a failure in the way that the process is implemented and not a condemnation of what the process is attempting to achieve.
The best way to produce effective processes is to make sure that managers and employees are specifically and directly responsible for the success of the process while providing avenues to change the process (but not eliminate it nor trivialize it.) If your bonus and your managers bonus is directly based on the success of your processes then both of you are going to be more invested in making it work.
Stop edit wars of taste, and close a trivial discussion once and for all, see also bikeshedding[^].
A coding standard is the first thing to get before doing formal code reviews (When asking about what to prepare for a code review, I was surprised how highly this ranked. Now I know.) It doesn't even need to force one single specific style, it can allow different bracings, etc. A professional developers can stick to a coding style, even if it's not his favorite. If they can't, you need to agree on - or decree - an automatted formatting macro that is used for dispute resolution.
Code Reviews are hard socially. We have better experience with informal ones ("Can we look together at...") - but they don't happen as often as I wanted to. I've read of others praising the advantages of formal ones.
Code reviews can be a way of educating developers and also a way to insure that tribal knowledge increases.
And that is often a good thing.
Ah, to work in such a wonderful environment.
Instead, the places I've worked, the managers expected that ALL bugs would be located and failure to do so would rain hell upon those involved in the review.
"When the going gets tough, the tough take meetings" seemed to be their operating motto.
I once had to endure three days of meetings which called into to question my knowledge of the product, my knowledge of the language, my knowledge of programming principles, and my genealogy, because I had faithfully rewritten a module as a workalike that exposed a bug (not in my code) that went from non-reproducible to an absolute certainty.
While I was having my tongue nailed to the tabletop, one of my colleagues found the bug and the bug reports of it.
Calling it a failure of management would be an understatement. I have yet to discover how one can make a change to management, short of leaving the company.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
There's a name for craftsmen that blame their tools, it's on the tip of my tongue.
Code reviews are socially hard (which for some developers ranks slightly above NP-hard). As much as I despise "This is John Consultant, he will be with us for two days and tell you how to do your job", this is one situation where an external authority to drill individuals isn't the worst solution.
It is problematic to get the right people behind it, and if it doesn't work by its own, you have to impose ridculously rigid rules.
Not that you have to do code reviews, and there are likely shops who would never get it done. just don't throw out the coconut because the peel is so hard.
Steve McConnell, "Code Complete", cites a comparison of verious "bug slaying" methods.
The main message is: no single one is sufficient.
The second is: formal code reviews rank highest or second-highest. (McConnell informally concludes in conjunction with other arguments that anything that makes someone read the code is pretty damn efficient.)
At home I can look up the original paper (though havign that book is kinda recommended anyway )