My Pair Programming Diary

Dave Schinkel
Dec 12, 2019 · 3 min read

note: The current diary is long so it’ll take some time to get all of what I have jotted down transported to this blog post so far for 2019.


  • As a Sr. Software Artisan, I pair program and TDD daily where I work; we are an XP shop
  • I usually learn many things each day, no matter how experienced I think I may be
  • Because I learn so much, I can’t remember half the shit I’ve learned — information overload :), so I keep a diary that I can reflect on and go back and apply some of what I forgot (some of these develop into habits, some I forget)
  • You’re not seeing everything I write down, just more of the generic bits from each day that might benefit programmers in general
  • I learn exponentially more when I pair vs. programming solo and we get a lot more done than if we programmed solo

I try to write down daily new things I learn or things I simply forgot about and made it a point to write down as I pair with different people. I think it’s a smart thing to do personally.

This blog post is a running list of things jotted down by date. Will anyone find value in scrolling down this super long blog post as I keep adding days to it? I have no idea, this is an experiment, we’ll find out. And remember you can bookmark lines of text in here for your own notes.

I Hope you learn something from these notes. If you find this post valuable, give it some love (claps) and please share with others.


Team Decision: To do pull requests with required code review or not?

  • Depends on each team whether to PR or not. Even though PRs could defeat the purpose of continuous integration or deployment and possibly slow that down and become bottlenecks, the team decided there is value to doing PRs still and that we’ll do PRs as long as other pairs stop and help get new PRs reviewed. A team norm will be not to let PRs sit. If nobody is looking at your PR, make it visible and be persistent on getting another pair to stop and look at the PR. If we find PRs to be no longer valuable, bring it up in next retro
  • How many code reviewers do we need? Another pair only
  • Benefits of PRs even in an XP shop (even though we’re all code reviewing real-time as we pair)
    1) You get another set of eyes on it to catch stuff we did not see both on the code design side as well as ensuring the code works (yes our tests are green but spin it up and see what you think about it…does it work for you? does it still make sense?)
    2) Other pairs learn what you did, so just some additional cross pollination / sharing knowledge during each sprint


  • Android: don’t forget to register your custom service in the App manifest!
  • Kotlin: a language developed by JetBrains that compiles to Java and a ton more elegant and fun to code in than Java. You can also intermix Java and Kotlin together in one project and use both languages if you wish.
  • Kotlin: in Java to call a getter you’d do something like getSomething .In Kotlin it’s just something
  • Kotlin: to extend a class you simply use :unlike Java where you’d use the extends keyword


  • In JetBrains products (IntelliJ, WebStorm, etc), when debugging, simply click the play button again in the debugger pane to quickly jump/resume to the next debug point

more updates soon…

Dave Schinkel

Written by

Software Crafter who pair programs & TDD’s daily. Past: Lead Crafter at 8th Light. Test Driven Development Practitioner. I run &

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade