Barney Dellar

About a year ago, I went to the Agile New England conference on Mob Programming ( https://2018.agilegamesnewengland.com/index.php/mob-programming-conference ). For some reason, I had booked crazy flights. I headed out from home at 3:30am to get to Boston... So I arrived in a fairly wired state. I took the bus out to Burlington. Because why wouldn’t I? Of course, I then found myself walking along the edge of the freeway for half a mile. And felt even more out of place.  The conference itself was amazing. But the highlight was Jessica Kerr’s keynote on the Camerata and the origins of Opera ( https://the-composition.com/the-origins-of-opera-and-the-future-of-programming-bcdaf8fbe960 ). I spent a great evening in the bar that night talking to Jessica and Llewelyn Falco about teleportation, beer, symmathecy, museums, healthcare... It was a good night.  After the conference, I went through to Boston with a couple of other folk, and spent the day walking the Freedom Trail. This was a love

Naming things is hard.  Naming things is very hard.  And, in software, we often want to name things when we know least about them. We create a variable that we plan to use later. What should it be called? How should it be used? We only have a vague plan at this point. And plans, of course, can change.  In my mob, we sometimes struggled to name things. And we would then fall into long discussions about what to call a variable. This often felt like bike-shedding, but we wanted a good name, so we carried on talking.  Then one day, we came up with a new plan. If we couldn’t name something within ten seconds, the person at the keyboard would just hit the keys at random and produce a gibberish name.  We would then use this unpronounceable name in the code, and move on.  And, as we moved on, we would have to talk about the unpronounceable thing. So we call it by what is was doing, by how we were using it. And, often, the name would then become apparent.  By not naming things in our code, by