QCon 2018 – Mob programming mini workshop

Title: Mob programming mini workshop: a whole team approach to the code
Speaker: Harold Shinsato

See the table of contents for more blog posts from the conference.

[I’ve heard this term before, but never experienced it. Curious to see how this goes!]


  • “All the brilliant people working on the same thing, the the same time, in the same space, on the same computer” – Woody Zuill
  • Turn up the good.  A team would rotate who types to solve the problem.
  • Far less bugs/tech debt
  • More productive than working individually [that’s not the right comparison]
  • Harold uses at Montano code school.
  • Requires kindness, consideration and respect. Takes time to learn. Psychological safety and empathy are important.
  • The team decides what to do and how to do it. Can’t force it. Just like forced pair programming doesn’t work.
  • Important to go in with plan to experiment and see what works.
  • Mobs of three good for coaching. Hunter uses mobs of 5-8.
  • Rotation time varies. Can switch every 15 minutes or just have one driver.
  • Mob worked with 50 people with language puzzles to learn/work through koans.
  • Introverts need to check out regularly. And that is ok (for mobs larger than 5) because flow continues. A teammate catches up on what you miss.
  • Gets people up to speed faster.


  • Coach
  • Driver – typist. Can’t have ideas. Just types. Smart input device.
  • Navigator – everyone else. Helpful to start with one navigator so can practice not talking when know answer. Need others to practice leadership and develop expertise.

Problems with pairing

  • Like a date. Awkward if doesn’t work out.
  • Mobbing is safer because in a group. No one person is a single point of failure.
  • Mobbing makes it easier to pair later. Harold uses mobbing before students pair

Strong pairing – where person at keyboard can’t make decisions

Demo – FizzBuzz in JavaScript

  • Updated JavaScript to make tests pass
  • Driver rotated on time or on passing tests. Time better for teaching as rotate faster. Did short iteration of 3 minutes to practice swapping.

Group Retrospective

  • It was obvious to me what needed to be done before it was to the navigator. It felt awkward and timewasting to not say anything
  • It felt really slow [probably because we were all new]
  • As driver, I wanted to go faster than the navigator
  • Hard to see vision. In a real mob, might draw out a plan

In practice

  • Supposed to improve team in long run
  • If someone knows most, they are primary navigator and turn into a leader – helping others.
  • Get better at using tools
  • Mobs of 8 good for teaching
  • Hunter is most experienced of mobs. Switch every 15 minutes.
  • Can speak at higher level if driver understands.

An audience member at Vanguard says her team does this once a day with eight developers.

My take

It would have been helpful to explain what mob programming is before asking who does it and for details. It was interesting to try. I would have liked seeing a video of a good mob doing it too. I can see how this is helpful for learning, but not actual tasks. Which is what people said about pairing at first. (or still do.) So I recognize that I don’t  have enough information/background to appreciate that.

After the session, I talked with an attendee who works at Vanguard. She says they do mobbing at two points:

  • for an hour a day to accomplish a stretch goal (where it sounds like the whole team is learning together)
  • organically – when one person ask another for help, who pulls in another and before long the whole team is involved

QCon 2018 – Invest in your Java Katalogue

Title: Invest in your Java Katalog: Managing Java Version Changes on the Rapid Release Train
Speaker: Don Raab & Aditi Mantri

See the table of contents for more blog posts from the conference.

Links to Katas

  • Oriinal Katas – http://codekata.com
  • On GitHub: https://github.com/BNYMellon/CodeKatas


  • Hands on programming exercies to hone your skills through practice
  • Styles
    • Refactor  code and tests should keep passing
    • Fix the code – write code to make tests pass
    • Fix the tests – write tests using API
    • Sandbox – free  form

Learning by teaching

  • Must learn something better to teach it
  • Develop katas to teach others
  • Practice through repetition

How to build a kata

  • Identify what want to learn (ex library feature)
  • Design a problem to solveWrite unit tests demonstrating how feature works
  • Implement code
  • Add helpful comments and hints so becomes standalone
  • Delete parts of code that want someone to learn

Live coding

  • Java lambda kata – refactor the code style
    • showed Java 10 var
    • showed effectively final
    • showed converting anonymous inner class to a lambda – used IntelliJ to do conversion. Showed casting so could keep using var. Said don’t recommend [I would have shown it without var. Using the type is far better than using var there]
    • showed converting lambda to method references
  • Deck of cards kata – fix the code style
    • Showed code using stream APIs and custom APIs
    • Showed Java 10 Collectors.ofImmutableList()
    • showed Java 10 Map.copyOf() to make immutable map
    • Showed using some of the APIs in   Eclipse Collections
  • Donut kata – fix the code style
    • Showed code using advanced Eclipse Collections
  • Calendar kata – fix the code style
    • showed Java  8 dates, Eclipse collections, etc
    • showed three ten library (extension of Eclipse collections?)


My take

I like the emphasis on using  live code (doing the katas) to reinforce the concepts taught earlier in the session. I learned about an API in Java 10 that I missed as well.  I  was a little confused by the “Eclipse Collection style of Kata” comment. That’s a kata, not one of the described type. Then I realized it was still part of the deck of cards kata so a “fix the code” style one.

QCon 2018 – Ask me Anything – Josh Bloch

Title: AMA (ask me anyhing)
Speaker: Joshua Bloch @joshbloch

See the table of contents for more blog posts from the conference.


  • Idea expression dichotomy – Words copyrightable but not ideas. Methods of operations not copyrightable  like QWERTY
  • Ideas may be protected by patents so can’t reimplement for 20 years. Ex: +++ on Hayes Modem
  • Now legal strategy to include a patent in copyright so goes to desirable court
  • Technically implementing your own list is a problem. But selective enforcement implies won’t enforce.

Microsoft vs Sun

  • had signed agreement and fought
  • not broader implications


  • How document scalability, performance and other non-logical constraints? Better to specify even if implmentations get to choose. That way it is specified that can’t rely on.
  • Some requirements/behavior is in spec when buy a product. Not just in API. Ex: copy machine can make X copies a second while API is press button to make copy.
  • Balancing act – don’t want implementation details in API that might change as callers will rely on them. But if not enough, developers assume/infer


  • Eventually languages keel over from own weight. Good thing.   Just like people, not meant to live forever.
  • Need to decide what to learn
  • Need to decide which API to use.
  • Makes room for new entrants when people can’t deal with current languages
  • Not just language. Also VM, libraries, etc. Much harder to move away from a platform. Harder than moving off JVM  than changing from C to Java.
  • Josh’s favorite editors – IntelliJ and Emacs
  • Type erasure is present so could be migration compatible (vs a whole new collections library)
  • As languages age, some decisions make sense only due to history and past decisions.
  • Josh wishes Java supported unsigned integers and especially bytes. Gosling designed  by gut originally and was usually right. This was a bad one. He felt it would have been unneeded complexity. Solution is a library since not in the language
  • Josh would have added methods to return an arbitrary element and leave (or remove) from collection.
  • Josh would have returned Collection itself instead of a boolean as to state. That would have allowed fluent calls
  • Josh expects modules to get used mainly within the JDK

Java and six months release cycle

  • Platforms require stability. Can’t have major changes each 6 months.
  • Lots of stuff that in there and not used
  • Books released less frequently than release cycle even when more reasonable.
  • Changes minisule so not worth updating for each

Josh’s future

  • Josh teaching OO and APIs courses next semester
  • APIs course may turn into book on API design

My take

At Josh’s keynote, he commented that there was no time for questions, but there was this AMA. This was awesome! The people who were interested got to ask lots of questions and everyone else didn’t have to sit through it.