- Unterwegs zur Agile Bodensee #abkon #
- Stuck in traffic #abkon http://t.co/HMb5zcaI #
- Made it #abkon http://t.co/SFk91Zy2 #
- Real-Time Collaboration talk took off slowly but picking up steam now – Wolf Pack Programming #abkon #
- Very nice venue #abkon http://t.co/Fo3A3HtA #
- Stupendous talk by Joseph Pelrine on what Scrum really is #abkon #
- Joseph Pelrine talking about how Agile relates to hair loss #abkon #
- Lake view #abkon http://t.co/nzNVglyw #
- Scrum is not a goal, it's a starting point – Joseph Pelrine #abkon #
- "Doing Scrum is way harder than teaching or coaching it" – Joseph Pelrine #abkon #
- If you are doing Scrum by the book, you're not doing Scrum, you're following a religion – Josef Pelrine #abkon #
- @josephpelrine thoroughly enjoyed your talk – have a safe trip home! in reply to josephpelrine #
- Da bin ich einen Tag mal nicht im Büro und schon tritt Kurt zurück, Peer kandidiert, Michael fliegt raus und Tim entschuldigt sich. #
- RT @FridayBruceFix I fall down on my knees and I cry, its my way of saying goodbye #springsteen Today at http://t.co/Z8pMtC2T #
- @sybit_agile Vielen Dank für die perfekte Organisation eines informativen Tages zum Thema Agile. Selbst das Wetter habt ihr gut hinbekommen. #
(Should get this months old draft out there before the 2013 leg of the tour is upon us 😉
Not sure if I qualify as a Bruce Springsteen “fan”. With fandom, I do associate hysterical screaming (and I’m far from it). “Mild stalking” is another characterization I associate with fandom. Most certainly, I’m not interested in the private life of neither Bruce Springsteen nor members of the E Street Band.
However, I do care deeply about the music. Everybody has a certain kind of music which deeply resonates with him or her. And Bruce Springsteen’s music deeply resonates with me.
Frankfurt was special as I took my wife and my two older daughters with me. We got seats on the right hand side quite far from the stage. The concert, however, became absolutely magical as Bruce & the E Street band clearly loosened up in the last quarter of the concert. Summertime Blues in the main set came unexpected, and the departure from the standard encores played on the tour so far with Cadillac Ranch, Sherry Darling & Glory Days made my day.
For Cologne, a slightly more intimate stadium than Frankfurt, I managed to get front of stage tickets. Unfortunately, I missed the pit roll calls by about 15minutes (shouldn’t have stopped for a bathroom break during the 2.5h drive to Cologne ;-), but found a nice, relatively short queue in the shades. Met a few nice folks who provided me with priceless advice on how to convince my wife to do a few more Springsteen concerts (Hint: Trade shopping/sightseeing in Milan/Florence for spending the evening at Springsteen concerts). I got lucky and ended up maybe 12th “row” on the left side of the stage, with a great view of the fantastic performance and hard work Nils Lofgren is putting into the show.
For the Berlin trip (kindly sponsored by my aforementioned wife), I showed up early at the Berlin Olympic Stadium, got my number (171) and spent the day either queueing, showing up for the roll call or queueing & reading (Recommend classic car magazines). A worthwhile effort, as I got a great spot in the pit (about 5th row) on the right side of the stage right in front of Steven van Zandt. The big news was, of course, the opening song “When I leave Berlin” which was extensively rehearsed during the soundcheck and an absolutely beautiful rendition of “Save my Love”.
I didn’t expect the Wrecking Ball material to be a perfect fit for a stadium setting. Of course, I was wrong. It worked out great, lot’s of feedback from the audience.
Was it worthwhile? You bet. Rumors suggest that there might be a second european leg next year (Munich? Hamburg?) I’m very much looking forward to it, maybe “Racing in the Street” this time? I hope to put the free advice I got in Cologne to good use and try to get a few more 2013 concerts in Italy or Spain on my schedule.
Pro tip: Get a Mophie Juice Pack Plus for your iPhone if you intend to tweet the setlist. It’s $§&! ugly (the Mophie, not the setlist), but it will double your battery capacity during the show. And trust me, you’ll need it as you’re desperately trying to get your tweets through the congested ether at the venue.
The following quote from Buzz Andersen’s blog (which I highly recommend) caught my eye:
…full-time pairing can make the certain amount of “staring into space” time every programmer needs to get things right excruciatingly awkward.
I don’t want to dive into the pair programming discussion this time, I’ll leave this for another post. I would like to talk about staring. Staring on the code. Staring on a comment. Staring on a UML design sketch. Or, as Buzz puts it, staring into space. (*)
As far as I can tell (and I have done my fair share of staring over the years), staring is a software engineering technique where, for an extend period of time, the software developer refrains from any movement of his extremities, stops moving his eyeballs and focusses on a particular piece of code, while his CPU cores, umm, brain runs at 100% load trying to solve the problem at hand.
If we’re lucky, said developer appears to wake up from time to time, types a few characters, maybe adds a comment and resumes staring. If we’re less lucky, said developer will remain unresponsive for extended amounts of time and will make no measurable progress towards his goal.
I don’t dispute that “Staring” may be a technique to get things right, but I would like to go on the record that it’s an efficient technique to get things right. Day after day, I observe that developers “stare into space” or, even more inefficient, “stare on the code” in order to solve problems. However, I’ve never seen a problem getting solved by staring, I’ve only seen problems getting solved by adding or changing code.
Why is staring an inefficient technique, you may ask?
Staring is inefficient because it doesn’t employ a feedback loop. You are reasoning about the code with yourself. Nothing wrong with it, but there’s no one involved giving you feedback on your thoughts or challenging your assumptions – after all, it’s just you staring at the code.
If you catch yourself staring at code too often, make sure to get into the habit of doing something with the code instead:
- Even if you don’t have automated tests (and you know you should, don’t you), you can do tiny, lowest-risk refactorings which help you deepen your understanding of the code just a tiny little bit. Rename a variable, a function, extract a few lines of code to a new method, write a comment (gasp), change the formatting to suit your style (quadruple gasp). You can always revert this changes after you understood what’s going on (you do use version control, don’t you?)
- How about running the code in a debugger to get the additional feedback of variable / objects / state changes at runtime?
- How about writing unit tests? Write a test, write a little bit of code, write some more code, see a test failing, change the code, write a test to test your assumptions about specific parts of the code. Do a change to the codebase to learn something? Do the tests still run? Great. They don’t? Looks like your assumptions were wrong. Trace back, take another route.
If you absolutely must “stare” at the code, I suggest to take a step back and “sleep on it” or to take a short walk. But those are techniques which should be reserved to occasions when you really got stuck and you’re trying to solve really hard problems. Guess what, most of the time the problems aren’t that hard. They may be challenging but they are quite solvable by taking tiny, reproducible (sometimes revertible) steps towards a solution.
Code is like clay. Make sure to mold it. Carefully. You’ll learn way more by molding the code, not by staring at it.
(*) Don’t want to get into discussing “staring on web-sites not at all related to the task at hand” either.
- @indigoblur 4th row? Wow. Make sure to stream those of us not there some pictures… #springsteen in reply to indigoblur #
- RT @tnm First rule of debugging: it's never what you think it is. Second rule: it's not that other thing either. #
- First rule of optimizing for performance: it's never what you think it is. Second rule: it's not that other thing either. /cc @tnm #
- Also Google Maps war schöner #ios6 #maps #
- Listening to Devils & Dust tour bootleg I conclude that skipping the D&D tour was a definite mistake. #springsteen #
- Ich lehne mich mal weit aus dem Fenster und sage: Steve hätte das so nicht freigegeben. #ios6 #maps #fb #
- Steve wouldn't have shipped #ios6 #maps. There, I said it. #fb #
- Softwerkskammer Karlsruhe #13 (@ DJK Ost) http://t.co/HrV6CRJo #
- Great discussion on code smells @ @softwerkskammer Karlsruhe Meeting #13 – Thanks to @weltraumschaf for providing his codebase. #fb #