Agile Otter Blog

A few ideas rattling around my head need a place to live while I think them through, so I am shoveling them into the ole blog so I can think about prepping materials and exercises for a class I am teaching soon. I was considering an archetype developer that we've all seen (heck, half of us have been ) and how hard it is to reach this particular type when doing any kind of a technology or methodology change.  Here's the stream: There is this guy who believes he's an exceptional programmer, but underrated and under-respected by his peers. Why does he think he's good? Maybe he doesn't really believe it. maybe he's afraid. (@RonJeffries) A guy who never thinks or reads about programming off-hours, never goes to talks, hates pairing, skips reviews. Thinks himself an expert? b/c folks like that have a Darwinistic career advantage over peers who /are/ good but think they're mediocre/overpaid/overrated (@LancePurple). I suspect Dunning-Kruger Effect . Not go...

Your team is hard at work, testing and coding and planning, and suddenly the build breaks. Now what can you do? The broken build might not be your fault at all, and besides you have work of your own to do. You could go ahead and practice business-as-usual, but this is probably a bad idea. Here's what I say: Never pull from a broken build . Assume that version control is poison. If you are not the one fixing the build (and shouldn't you be?) then you should leave it be. The last thing you want to do is import brokenness into your local build environment. Import from a "green" build, and you will know that any brokenness is your problem. Test locally before considering pushing code to the CI build, even though it takes a bit more time. There is really no good time to NOT know that you've broken something. A little "due diligence" goes a long way. Never push to the CI server if your local build is broken . If your build is broken, it inconveniences...