Craft Conference is cancelled.   More info

J. B. Rainsberger

Agile Coach, but really Agile and really a Coach at


Programming Is the Easy Part
organizing work
time management
energy management
simple design
evolutionary design

Your rating:

From the start of my career as a programmer, it took me only a few years to understand that my effectiveness depends on much more than merely by ability to write solid code. Unfortunately, I did not grow up with an intuitive understanding of how to organize my work nor how to navigate the complexities of other people. Not only did I have to learn those things, but I had to learn them from the point of view of the stereotypical ultra-rational programmer. I would like to share what I've learned with you.

We will begin with a summary of how to do excellent programming work, in case you don't already feel like you do that. After that, I will introduce a few simple techniques to help you deal with the problems that excellent programming work (alone) doesn't solve. Some of you will discover some new techniques missing from your toolbox; some of you will choose to refocus your energy away from programming onto another aspect of your professional development. Even if you don't discover anything new in this talk, I hope that you will walk away with renewed confidence that you are (already) on a path towards becoming an effective, well-rounded, content professional. If even one of you moves off the path towards burnout and depression, then that would make me very happy.


Agile Design: Beyond the Basics (2 days)
Tuesday+Wednesday 9:00 - 17:00 -
test-driven development
evolutionary design
Your rating:

In this workshop, we discuss the issues that programmers face who have practised evolutionary design techniques for (at least) several months on a professional-grade project. It is not an introduction to test-driven development, but rather what comes next: a chance to discuss and practise issues that arise once you become comfortable with the elementary ideas of evolutionary design (how to write a test, writing the tests first, ...)

Through a combination of practice and discussion, we will address ideas that programmers often struggle with once they master the basics, including these ones:

  • how to use test doubles (mock objects) as a design tool as well as for testing, choosing when to trust their intuition and when to "follow the rules"
  • how to decide which tests you need to write, including how "simple" is "too simple to break"
  • how to safely extend your evolutionary design practice to evolutionary architecture
  • how to manage the conflict between collective code ownership and the group's evolving understanding of "good design" and "bad design"
  • how to balance refactoring with rewriting
  • how to balance intuitive (follow your instinct) and mechanical (follow "the rules") design decision-making
  • how to decide which kinds of tests to write: microtests, integrated tests, collaboration and contract tests, end-to-end tests, customer-facing tests, customer unit tests, ...

This is only a handful of common concerns and only a list of what we might discuss. The people in the room will drive the agenda for the workshop.

You will be able to write code in any programming language and environment that you like. We will work on my sample project. I encourage people to work in groups of 2-4 people each, but if you strongly prefer to work alone, you are welcome to do that.

Please come to this workshop with the following:

  • a computer prepared to write code--you are ready if you have an empty project where you can running a failing test and commit changes to version control (something lightweight like git, hg, darcs, bzr...)
  • something to write with and something to write on (notebook, index cards, sticky notes...)
  • your toughest questions and your deepest concerns

You will leave this workshop with:

  • some working, well-designed code
  • notes, a list of articles and book references, pictures of all the flipcharts/diagrams that we draw
  • confidence to defer even more design decisions to the last responsible moment


J. B. Rainsberger (@jbrains) helps companies profit sooner from delivering software while he helps people work with more joy and less stress. He travels the world for part of the year sharing what he's learned about programming, managing his work, building great relationships with people, and designing his lifestyle. The rest of the year he helps clients remotely, writes, and coaches people one on one. You can find his blogs at (mostly about programming) and at (mostly about everything else). He lives in Atlantic Canada with his wife, Sarah.