-----Original Message----- From: everything-list@googlegroups.com [mailto:everything-list@googlegroups.com] On Behalf Of Russell Standish Sent: Friday, March 28, 2014 12:03 AM
> Yes, although I think you get (easier) second chances with programming. > > LOL that you do. though in many big environments if you break the > build once you get to eat raw broccoli; you break it twice you're > fired. So then again perhaps not, in some cases. > >> That's tough love! In my last team, you had to buy the wine for the next team lunch if you broke the build. I like that better :) The eat raw broccoli lore comes from the windows team at Microsoft. For a team of that size breaking the build is actually a big deal with large downstream follow on costs, as literally many hundreds of engineers get idled, delivery dates get slipped and so forth. >>That way: a) discourages you from being too cavalier with your submits, b) mollifies your team-mates who might have had to have dealt with consequences of the broken build and c) doesn't scare you shitless about having to commit something that might break the build and possibly lose your job. I agree -- Draconian punishment rarely encourages creative solutions, and, in fact can lead to a situation where everyone conforms to a culture of not touching anything for fear of breaking it. To be fair -- to the Windows team at MS -- no one would lose their job if the build got broken for reasons which the programmer who submitted the changes could not have easily avoided. However if some stupid bug in the checked in code -- that should have been caught in unit testing -- was the culprit that brought the whole thing down then the heat would be applied. >>If you've ever had to deal with a screwed subversion system after trying to upgrade your boost libraries, or after trying to upgrade you Visual Studio version, you'll know there are times when breaking the build is inevitable. Also, if the build times are on the order of 3 hours (as it was in one place), then the "no break the build" policy means that you cannot do a commit after 11am, otherwise you potentially will be staying back after work to fix the build. In that job I used to get everything to the commit stage, then go home. There was an automatic script that synced the repository to my local copy and built as much as possible. When I got in next morning, I did another sync, and build, and usually I was lucky that that finishes by 11am, so that I can commit that day. If not, I'd spend the rest of the day trying to fix my local build, and once that was done, catch up on code reviews, as I couldn't actually do any new coding until I had successfully committed the previous stuff the following day. LOL I have! Or when you have some large -- multi-file checkin -- with a lot of changes in it that is unlucky enough to be on the end of a three or more way resolve full of conflicts. I worked on one team where the build would take around 4 hours (or longer) and they had a 1pm policy. In that case the build script itself was generated by a whole series of other pre-processing scripts which actually generated the build script based on a slew of factors including a lot of environment type factors. >>I much preferred the situation where I could bribe my colleagues with a few glasses of wine if I needed to. Also, I have done my share of remote login to check and fix builds after hours, but that's not always feasible when you've got family depending on your being home. Remote login is a double edged sword. On the one hand it is so convenient to be able to remotely tunnel in and do things like check in on the state of some long running process, and be able to address issues that may be blocking it or causing it to hang, without having to make the drive. Really like that aspect. On the other hand it opens up the door to the "working from home" trap. When I get home I really don't want work following me... and in our business it definitely has the tendency to want to do just that. Like it has with me these last months on this very large scale data mining project I am on Cheers, Chris -- ---------------------------------------------------------------------------- Prof Russell Standish Phone 0425 253119 (mobile) Principal, High Performance Coders Visiting Professor of Mathematics hpco...@hpcoders.com.au University of New South Wales http://www.hpcoders.com.au Latest project: The Amoeba's Secret (http://www.hpcoders.com.au/AmoebasSecret.html) ---------------------------------------------------------------------------- -- You received this message because you are subscribed to the Google Groups "Everything List" group. To unsubscribe from this group and stop receiving emails from it, send an email to everything-list+unsubscr...@googlegroups.com. To post to this group, send email to everything-list@googlegroups.com. Visit this group at http://groups.google.com/group/everything-list. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Everything List" group. To unsubscribe from this group and stop receiving emails from it, send an email to everything-list+unsubscr...@googlegroups.com. To post to this group, send email to everything-list@googlegroups.com. Visit this group at http://groups.google.com/group/everything-list. For more options, visit https://groups.google.com/d/optout.
