Record of experiments, readings, links, videos and other things that I find on the long road.
Registro de experimentos, lecturas, links, vídeos y otras cosas que voy encontrando en el largo camino.
In the last quarter of 2017 we delivered several TDD trainings at Merkle’s offices in Barcelona and did several consulting session with their JavaScript and Java teams. Merkle is a company with high quality standards for the software they develop, so we were very happy when they contacted us to collaborate again this year doing several TDD trainings and consulting sessions.
So far we have done the first round of consulting sessions and the first of the TDD trainings. It was a very special one because it was the first test drive of our revamped training material. We have used the feedback from former training attendees to refine our TDD training material. We edited some parts that we thought were less valuable, and added new modules that reflects better the way we understand TDD at Codesai, so that the course is now more dynamic and easier to follow. We are looking forward to having the next consulting sessions and TDD trainings.
TDD training
We know that a two days introductory TDD training is not enough for a team to start doing TDD in a real environment. After the training, once the team returns to work, a lot of questions arise and the way to apply TDD is not always clear to them. In order to help Merkle’s teams in this process we are supplementing the TDD training with, on one hand, several rounds of consulting sessions in which we address together the difficulties that arise on the teams daily job, and, on the other hand, with one of the main novelties of this year’s collaboration with Merkle: a 4 months deliberate practice program. This program is aimed to improve the skills of a group of about 22 Merkle’s developers in object-oriented design, refactoring and TDD. We will give more details about it in a future post.
Deliberate Practice Program
Before finishing this post, we would love to thank Merkle (and especially Nelson Cardenas) for trusting us again to train their developers and help them grow their skills.
January
- The Plateau Effect: Getting from Stuck to Success, Bob Sullivan & Hugh Thompson
- The Thirty-Nine Steps, John Buchan
- Memento Mori, Muriel Spark
- Cosmonauta, Pep Brocal
- The Man Who Was Thursday: A Nightmare, G. K. Chesterton
- Ébano, Alberto Vázquez-Figueroa
- The Subtle Art of Not Giving a F*ck: A Counterintuitive Approach to Living a Good Life, Mark Manson
- The Importance of Being Earnest, Oscar Wilde
February
- The Maltese Falcon, Dashiell Hammett
- This Is Water, David Foster Wallace
- Judas, Amos OZ
- Never Let Me Go, Kazuo Ishiguro.
- Microservice Architecture: Aligning Principles, Practices, and Culture, Mike Amundsen, Matt McLarty, Ronnie Mitra, Irakli Nadareishvili
March
- On Anarchism, Noam Chomsky
- The Fire Next Time, James Baldwin
- Esperanza en la oscuridad, La historia jamás contada del poder de la gente (Hope in the Dark: Untold Histories, Wild Possibilities), Rebecca Solnit
- The Dispossessed: An Ambiguous Utopia, Ursula K. Leguin
- Release It!: Design and Deploy Production-Ready Software, Michael T. Nygard
April
- Sin blanca en Paris y Londres (Down and Out in Paris and London), George Orwell
- The Garden of the Finzi-Continis (Il giardino dei Finzi-Contini), Giorgio Bassani
- Test Driven Development: By Example, Kent Beck (2nd time)
- Just Enough: Tools for Creating Success in Your Work and Life, Laura Nash and Howard Stevenson
- The Left Hand of Darkness, Ursula K. Leguin
- The Heat of the Day, Elizabeth Bowen
May
- Radetzky March (Radetzkymarsch), Joseph Roth
- Death of a Salesman, Arthur Miller
- A Raisin in the Sun, Lorraine Hansberry
- Improve Your People Skills: Build and Manage Relationships, Communicate Effectively, Understand Others, and Become the Ultimate People Person, Patrick King
- Flatland: A Romance of Many Dimensions, Edwin Abbott
- The Hard Truth About Soft Skills: Workplace Lessons Smart People Wish They'd Learned Sooner, Peggy Klaus
June
- The Little Guide to Empathetic Technical Leadership, Alex Harms
- Patria, Fernando Aramburu
- How to Be an Imperfectionist: The New Way to Fearlessness, Confidence, and Freedom from Perfectionism, Stephen Guise
- Dragon's Egg, Robert L. Forward
Improving your reds is a simple tip that is described by Steve Freeman and Nat Pryce in their wonderful book Growing Object-Oriented Software, Guided by Tests. It consists in a small variation to the TDD cycle in which you watch the error message of your failing test and ask yourself if the information it gives you would make it easier to diagnose the origin of the problem in case this error appears as a regression in the future. If the answer is no, you improve the error message before going on to make the test pass.
From Growing Object-Oriented Software by Nat Pryce and Steve Freeman.
Investing time in improving your reds will prove very useful for your colleagues and yourself because the clearer the error message, the better the context to fix the regression error effectively. Most of the times, applying this small variation to the TDD cycle only requires a small effort. As a simple example, have a look at the following assertion and how it fails
Why is it failing? Will this error message help us know what’s happening if we see it in the future?
The answer is clearly no, but with little effort, we can add a bit of code to make the error message clearer (implementing the toString() method).
This error message is much clearer that the previous one and will help us to be more effective both while test-driving the code and if/when a regression error happens in the future, and we got this just by adding an implementation of toString() generated by our IDE.
Take that low hanging fruit, start improving your reds!
