Emily Bache is an independent consultant specializing in automated testing and agile methods. With over 15 years of experience working as a software developer in organizations as diverse as multinational corporation to small startup, she has learnt that to be truly agile, teams need to learn to use agile engineering practices. Emily is the author of “The Coding Dojo Handbook: a practical guide to creating a space where good programmers can become great programmers” and loves to coach and teach developers about Clean Code, Test Driven Development, Refactoring, and more. Emily speaks regularly at international events such as Agile Testing Days, XP2013, ACCU, and recently gave a keynote address at Test Automation Day in the Netherlands.
Keynote: As a Professional Programmer, how do you learn new skills?
In my experience, there are some skills that are hard to learn as a professional programmer. You learn a lot on the job, via trial and error, and coaching from your peers. Occasionally you go on a training course and learn the basics of a new framework or language. Neither of those ways is particularly effective when it comes to a skill like Test Driven Development.
There are several reasons for this. It’s hard to change the habits of a whole career in a two day class. Then when you get back to work you discover your system is not designed with testability in mind, and adding tests later is really difficult. Alternatively you may find yourself working on some kind of greenfield development where it should be easier. The trouble is you find writing tests slows you down so much, you have to abandon them as deadlines loom. In the best case, adding tests afterwards becomes the norm, and in the worst case they are not written at all.
I’ve found that having a regular forum for learning, called a “coding dojo”, can make all the difference to professionals who want to learn skills like Test Driven Development.
When you step into the coding dojo, you leave your daily coding environment, with all the associated complexities and problems, and enter a safe environment where you can try stuff out, make mistakes and learn with others. It’s a breathing space where the focus is not on delivering solutions, but rather on being aware of what you actually do when you produce code, and how to improve that process. The benefits multiply if you can arrange to bring your whole team with you into the dojo. Through discussion and practicing on exercises, you can make a lasting impact on the way you work together.
In this talk I’d like to explain what a coding dojo is, and why you might be interested to take part in one.
Workshop: Coding Dojo Challenge – SOLID design principles
In this hands-on session we will be looking at how the design of our code affects how easy it is to write tests for it, and how applying SOLID design principles helps with testability. We’ll be looking at several small pieces of code where the author has broken one or more SOLID principles, and trying to get that code safely covered with unit tests. Along the way we hope to learn more about good design and what makes for maintainable code.
We’ll be stepping into the Coding Dojo together, which is a safe place designed for learning, where it doesn’t matter if we make mistakes. In fact all the code will be thrown away afterwards. You should feel free to experiment, try out different styles of test, and get feedback from your peers.
We’re taking a simple, bounded problem, where the code basically works, and the requirements are largely understood. The idea is to practice your design and refactoring skills, and have fun doing it. We’re trying to provoke that “aha!” experience where you realize how much the simple demand to write the tests first can improve the design of the code you end up with. The intention is that after the session you’ll be better motivated and equipped to improve the design of the production code you write.